طبقة الخدمة مقابل طبقة الأعمال في تعليم تطبيقات الويب؟

Question

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

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

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

Answer 1

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

يتيح لك ذلك تطبيق أنماط التصميم المتخصصة وأفضل الممارسات على كل مكون.

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

هذا الدور من GO بين أفضل أداء بواسطة طبقة الخدمة. يتيح لك هذه الطبقة المتخصصة تطبيق أنماط أكثر تخصصًا على كل مكون فردي.

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

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

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

ASP.NET MVC ليس شيئًا إن لم يكن منصة لتمكينك من كتابة تطبيقاتك كمكونات متخصصة.

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

Answer 2

قد تجد المصطلح رائد الفضاء العمارة مثير للإعجاب.

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

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

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

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

Answer 3

في بعض التصميمات ، لا يتم استخدام طبقة الخدمة بواسطة طبقة العرض التقديمي.

يتم استدعاء طبقة الخدمة من خلال التطبيقات الأخرى التي ترغب في استخدام طبقات الوصول إلى الأعمال والبيانات في التطبيق.

بطريقة ما ، طبقة الخدمة هي واجهة أخرى منفصلة عن طبقة العرض التقديمي.

انظر الرسم البياني المعماري هنا. يقوم المستخدمون بالوصول إلى التطبيق من خلال طبقة العرض التقديمي. والأنظمة الخارجية تصل إلى التطبيق من خلال طبقة الخدمات. تتحدث طبقة العرض التقديمي وطبقة الخدمات إلى واجهة التطبيق في طبقة العمل.

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

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

Answer 4

عادة ما يتم إنشاء طبقة الخدمة من حيث العمليات المنفصلة التي يجب دعمها للعميل.

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

في كثير من الأحيان ، تستخدم طبقة الخدمة رمز نمط البرنامج النصي الإجرائي أو المعاملة لتنظيم طبقات الأعمال و/أو المنطق.

مع العلم بذلك ، قد تدرك ذلك لك طبقة العمل حقا هو طبقة خدمة كذلك. في مرحلة ما ، النقطة التي تطرح منها أن تكون هذا السؤال من هذه النقطة ، يكون التمييز في الغالب دلالات.

Answer 5

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

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

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

لا يحتاج كل تطبيق على واحد على الرغم من أن الكثير من المتغيرات تدخل في هذا القرار) ، يمكن للعمارة التي يمكن أن تقدم الكثير من التعقيدات التي قد لا يحتاجها فريقك.

Answer 6

ألق نظرة على ما يقوله راندي ستافورد عن طبقة الخدمة في كتاب "P of EAA"http://martinfowler.com/eaacatalog/servicelayer.html

تحدد طبقة الخدمة حدود التطبيق [Cockburn Plop] ومجموعة من العمليات المتاحة من منظور تواصل طبقات العميل. إنه يلف منطق أعمال التطبيق، السيطرة على المعاملات واستجابات تصحيح coor في تنفيذ عملياتها.

Answer 7

بسيط. لفضح منطق عملك للعميل ، استخدم طبقة خدمة. اسال نفسك:

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

Answer 8

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

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

في نهاية المطاف ، أرى أن طبقة العمل أكثر حبيبية ، في حين أن طبقة الخدمة يمكن أن تكون أكثر خشونة من حيث أنها يمكن أن تسمي عمليات متعددة في BLL ، وطلب المكالمات ضمن مكالمة خدمة واحدة.

Answer 9

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