ASP.NET MVC مع طبقة الخدمة وطبقة المستودع ، أين يجب تعريف الواجهات؟

Question

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

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

والسؤال هو ، أين يجب أن أعرّف iRepository و iservice؟ كل من مشاريع الخدمة والمستودعات تحتاج إلى الرجوع إليها ، بالطبع. يبدو من الواضح بعد ذلك أنه ينبغي تعريفها في مشروع آخر يشير إليه كل من مشاريع الخدمة والمستودعات. إذا كان الأمر كذلك ، فماذا سيكون اتفاقية تسمية جيدة؟ شيء مثل xxxxcontracts؟

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

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

Answer 1

مقدمة

هذا شيء سألت نفسي أيضًا. سؤال واحد محترق لدي دائمًا مشابه لك ؛

ماذا سيكون اتفاقية تسمية جيدة؟

كيف يمكنني تسمية الأشياء؟ هل يجب أن يذهبوا في المجلدات أو المشاريع؟

بعد البحث حولها ، أظن أن الجواب هو ذلك لا يهم حقًا. المهم هو أن الحل يكون لديه بعض الهندسة المعمارية وأنك تحاول اتباع الممارسات الجيدة مثل صلب.

أبطال ASP.NET MVC حول هذا الموضوع جيفري باليرمو, ستيف سميث و جيمي بوجارد.

العمارة البصل

يناقش جيفري باليرمو مزيجًا من الأفكار القديمة ولكنه يجمعها ويعطيها الاسم المحفز بصريًا لـ العمارة البصل (قراءة موصى بها). يظهر جيفري مقاربة جيدة لمشكلة مكان وضع الأشياء. يوضح أنه في المركز (أو الأعلى) من طلبك لديك جوهر. هذه الطبقة هي المكان الذي يجب أن تضع فيه واجهات مثل IRepository و IService.

يجب أن تسير جميع واجهاتك تقريبًا في قلبها ويمكن لأي شيء آخر (مشاريع أخرى) أن يشير إلى جوهرها. وبهذه الطريقة ، يعرف كل شيء الهيكل العظمي للتطبيق دون معرفة تفاصيل التنفيذ.

حاول أن يكون لديك مرجع طبقة واجهة المستخدم بأقل قدر ممكن (في حدود العقل). في أحد تطبيقاتي ، تشير طبقة واجهة المستخدم الخاصة بي (MVC) فقط. يتم حقن كل ما يحتاج إليه حقن التبعية.

يناقش ستيف سميث هندسة البصل والأفكار المماثلة مع المظاهرات في أفضل الممارسات حلول MVC: حل لمشكلة الحل

بلدي الحل

في حلول MVC الخاصة بي ، لدي بنية نموذجية مثل هذا:

• myProject.core
• myproject.domain
• myProject.dependencyInjection
• myProject.Infrancture
• myproject.web
• myProject.tests

ال جوهر يحتوي على واجهاتي. عادة ما يتم تقسيمها إلى مجلدات مثل الخدمات والنماذج والمجال والمستودعات وما إلى ذلك.

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

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

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

ال الويب الطبقة هي مشروع MVC الخاص بي ويشير فقط إلى جوهر.

التعقيد والأفكار النهائية

لقد وجدت إجابات على أسئلة مماثلة هنا ، لكنها تميل إلى إشراك بنية أكثر تعقيدًا مما أوجزته هنا

إنها نقطة جيدة. من المهم أن تضع في اعتبارك تعقيد مشكلتك. لكن لا تردع من خلال ممارسات الحل الجيدة. إن حلتي والبصل ليست بالضرورة معقدة للغاية ولا تتفاقم حقًا الحل. إنهم يبقيون الأمور منفصلين فقط.

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

تذكر أن تأخذ الحل الخاص بي فقط كفكرة - شيء يجب مراعاته ؛ مقاربي هي محاولة لمتابعة نصيحة Sage من الأفضل ، لكنني متأكد من أنني نجحت كثيرًا فقط ؛ يمكنني (ويجب) التحسن.