الغرض من طبقة الخدمة و ASP.NET MVC 2

Question

في محاولة لفهم MVC 2 ومحاولة جعل شركتي تبنيها كمنصة قابلة للتطوير في المستقبل ، كنت أقوم بالكثير من القراءة مؤخرًا. بعد أن عملت مع ASP.NET بشكل حصري على مدار السنوات القليلة الماضية ، كان لدي بعض اللحاق بالركب.

حاليًا ، أفهم نمط المستودع ، والنماذج ، وحدات التحكم ، وشروط البيانات ، وما إلى ذلك ، ولكن هناك شيء واحد يمنعني من فهم تمامًا لبدء العمل على تطبيق مرجعي.

الأول هو نمط طبقة الخدمة. لقد قرأت العديد من منشورات المدونة والأسئلة هنا على Stack Overflow ، لكنني ما زلت لا أفهم تمامًا الغرض من هذا النمط. لقد شاهدت سلسلة الفيديو بأكملها في MVCCentral على تطبيق Golf Tracker ، ونظرت أيضًا إلى الرمز التجريبي الذي نشره ويبدو لي مثل طبقة الخدمة ليست سوى غلاف آخر حول نمط المستودع الذي لا يؤدي أي عمل على الإطلاق.

قرأت أيضًا هذا المنشور: http://www.asp.net/learn/mvc/tutorial-38-cs.aspx ويبدو أنه يجيب إلى حد ما على سؤالي ، ومع ذلك ، إذا كنت تستخدم تعليقات البيانات لتنفيذ التحقق من الصحة ، فإن هذا يبدو غير ضروري.

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

هل يمكن لأي شخص أن يزودني بالصف الثاني (حسنًا ، ربما الصف الخامس) لاستخدام هذا النمط ، وما الذي سأخسره إذا لم أفعل ، وما أكسبه إذا فعلت؟

Answer 1

في نمط MVC ، يكون لديك مسؤوليات مفصولة بين اللاعبين الثلاثة: النموذج والعرض ووحدة التحكم.

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

عادةً ما يتم نسخ النموذج احتياطيًا بواسطة قاعدة بيانات بحيث يكون لديك بعض DAOs الوصول إلى ذلك. يقوم عملك ببعض ... حسناً ... الأعمال ويخزن أو استرداد البيانات في/من قاعدة البيانات.

ولكن من ينسق DAOS؟ المتحكم؟ رقم! يجب أن يكون النموذج.

أدخل طبقة الخدمة. ستوفر طبقة الخدمة خدمة عالية لوحدة التحكم وستقوم بإدارة اللاعبين (DAO) الأخرى (DAOs ، والخدمات الأخرى ، إلخ) وراء الكواليس. أنه يحتوي على منطق العمل لتطبيقك.

ماذا يحدث إذا لم تستخدمه؟

سيتعين عليك وضع منطق العمل في مكان ما ، وعادة ما تكون الضحية هي وحدة التحكم.

إذا كانت وحدة التحكم مركزية على شبكة الإنترنت ، فسيتعين عليها تلقي مدخلاتها وتقديم الاستجابة كطلبات HTTP والاستجابات. ولكن ماذا لو كنت أرغب في الاتصال بتطبيقي (والوصول إلى العمل الذي يوفره) من تطبيق Windows الذي يتصل بـ RPC أو شيء آخر؟ ماذا بعد؟

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

توفر طبقة الخدمة التواصل مع DTOs والتي لا ترتبط بتنفيذ وحدة تحكم محددة. إذا كانت وحدة التحكم (بغض النظر عن نوع وحدة التحكم) توفر البيانات المناسبة (بدون مصدر) ، فستقوم طبقة الخدمة الخاصة بك بتقديم خدمة للمتصل وإخفاء المتصل من جميع مسؤوليات منطق العمل المعني.

Answer 2

يجب أن أقول إنني أتفق مع DPB مع ما ورد أعلاه ، فإن طبقة خدمة ie ie قابلة لإعادة الاستخدام ، قابلة للسخرية ، وأنا حاليًا في طور تضمين هذه الطبقة داخل تطبيقي ... إليك بعض المشكلات/ المتطلبات التي أفكر فيها (بسرعة كبيرة: P) يمكن أن يكون ذلك من المساعدة في Youeself ...
1. بوابات متعددة (على سبيل المثال بوابة المدونين ، بوابة العميل ، البوابة الداخلية) والتي ستكون ضرورية للوصول إليها من قبل العديد من المستخدمين المختلفين. يجب أن تكون جميعها منفصلة عن تطبيقات ASP.NET MVC (متطلب مهم)
2. داخل التطبيقات نفسها ، ستكون بعض المكالمات إلى قاعدة البيانات متشابهة ، والطرق والطريقة التي يتم بها التعامل مع البيانات من طبقة المستودع. لا شك أن بعض وحدات التحكم من كل وحدة/ بوابة ستجعل نسخة محملة تمامًا من نفس المكالمة ، وبالتالي هناك حاجة محتملة لطبقة خدمة (رمز للواجهات) والتي سأقوم بعد ذلك بتجميعها في مشروع فئة منفصل.
3. إذا قمت بإنشاء مشروع فئة منفصل لطبقة الخدمة الخاصة بي ، فقد أحتاج إلى فعل الشيء نفسه لطبقة البيانات أو دمجه مع طبقة الخدمة والحفاظ على النموذج بعيدًا عن مشروع الويب نفسه. على الأقل بهذه الطريقة مع نمو مشروعي ، يمكنني التخلص من طبقة الوصول إلى البيانات (أي linqtoSql -> nhibernate) ، أو يمكن لعضو الفريق دون العمل على أي رمز في أي مشروع آخر. الجانب السلبي يمكن أن يكون يمكن أن يفجر كل شيء لول ...