طبقة الخدمة مقابل كائنات المساعد؟

Question

أود أن يكون رأيك في حالة معينة من فضلك. هذا يتعلق بطبقة الخدمة مقابل كائنات Helper - وأنا لا أبحث عن أنماط مثالية، ولكن مجرد فهم جيد لما يفكر فيه زملائني البرمجة العزيزة في هذا:

في تطبيقي الحالي، لدي نموذج مجال كامل (LINQ إلى SQL، مستودعات خفيفة الوزن للغاية، ثم استخدم طرق التمديد عبر IQueryable <> للتصفية / الترتيب بناء على متطلبات العمل)، ثم طبقة خدمة تحتوي على خدمات استنادا إلى المجموعة من المسؤوليات، مثل iRegistrationService (تسجيل المستخدمين، والتحقق من توافر أسماء تسجيل الدخول وما إلى ذلك)

الآن التحذير. لدي أيضا بعض الفصول "المساعد" التي تقوم بأشياء مثل التشفير، ولدي أيضا محشوة العناصر الأخرى غير القابلة للتجزئة في هذا الدليل (مثل العادة المخصصة وما إلى ذلك)

أحتاج إلى إنشاء فئة جديدة الآن والتي ستتعامل مع جيل الروابط المخصصة للتطبيق الخاص بي، والذي بالكاد أكثر من string.format مع كائنات مختلفة وأخذ خصائصها في الاعتبار. العمل الداخلي غير ذي صلة. ومع ذلك، لدي صعوبة في إنهاء نوع من نوع "Linkservice" الآن، الذي سيحقق ذلك - أشعر أنني سأضعف مع 100 خدمات (وواجهاتها + تنفيذها) عندما انتهيت.

في الوقت نفسه، لا أشعر أنني أريد إنشاء بعض المزيج فضفاض من الفصول الدراسية وغيرها من الأشياء في مساحة الاسم / الدليل "المساعدين" (مثل LinkManager).

ما يجب القيام به؟ أين تضع الرجال الأشياء التي لا تزال مستوى طبقة العمل إلى حد ما، ولكن في نفس الوقت كيف تحد من عدد العناصر في طبقة عملك / الخدمة؟ أين تلتصق بجميع فئات المساعد الصغيرة هذه، مثل الكائنات الوسيطة التي تبسيط وإدارة الوصول إلى الجلسة (أفترض أنك تريد أن يكون لديك هذا مكتوب بشدة - على الأقل أفعل)؟

اسمحوا لي أن أعرف ما هو رأيك؟ شكرا !

Answer 1

بالنسبة لي، باستخدام الأداة المناسبة للمهمة هو المفتاح. إذا كنت بحاجة إلى نوع من المنشأة لإنشاء روابط، فهذا هو في الأساس تعيين خصائص الكيانات على الأوتار المنسقة، ثم اكتب منشأة للقيام بذلك. ليس من الضروري أن تكون خدمة ... على العكس من ذلك، امتلاك خدمة كاملة في المنفوخ لشيء من هذا القبيل هو المبالج. ومع ذلك، لن أتلق هذا فقط في "المساعدين" العام. يبدو أن هذا شيء له غرض ونوايا محددة، مع نوع معين من السلوك وراء ذلك. على هذا النحو، ضعها في موقع مناسب بشكل مناسب لهذا السلوك ... حتى لو كان هذا مشروع جديد.

لا أحاول عدم وجود رمز ضخمة من "عام" في تطبيقاتي. كل شيء لديه غرض ويقوم بتنفيذ سلوك محدد. في بعض الأحيان يكون هذا الغرض والسلوك قابلة لإعادة الاستخدام للغاية، لكن ما زلت أحاول تنظيم تلك العناصر القابلة لإعادة الاستخدام في مجالي منطقيا. من مستوى عال، أرى معظم تطبيقاتي مقسمة إلى ما يلي:

1. عميل
2. API / الخدمة
3. اختصاص
4. الوصول إلى البيانات (اختياري)
5. إطار العمل

الكثير من هذا النوع من الوظائف القابلة لإعادة الاستخدام يقع في نوع من منطقة Nether بين الإطار والمجال. قد توجد جزء منه على أنه بعض الفصول الأساسية و / أو الواجهات الأساسية وأنواع الدعم في الإطار، مع النصف الآخر، والتنفيذ الخرساني، المقيمين داخل نطاقي. يبدو أحيانا غريبا، ولكن تنظيمه بهذه الطريقة يساعدني في الحفاظ على مجالي نظيفا قدر الإمكان (مخصصا للمخاوف التجارية)، بينما لا يزال يتيح لي أن أجركت مفاهيم مشتركة وقابلة لإعادة الاستخدام في أنواع "إطار" منخفض المستوى.