طبقات خدمة WCF الطريق الصحيح

Question

وسؤالي هو أكثر من الطابع المعماري، أقل انخراطا مع التنفيذ الفعلي.

ولدي بناء API على أساس WCF، ولكن لا تستطيع أن تقرر حقا على كيفية فصل PL من BL. لقد جعلت من خدمة بلدي رقيقة، بحيث يحمل سوى الحد الأدنى من التنفيذ، شيء من هذا القبيل:

public TagItemResponse TagItem(TagItemRequest request)
{
   return (new ItemTagRequestProcessor()).GetResponse(request);
}

وثان بالطبع السؤال الذي يطرح نفسه الأول، في ما طبقة تفعل RequestProcessors تنتمي؟ وأعتقد أنه سيكون من الخطأ أن ندعو لهم واجهة، ولكن في الوقت نفسه، يتعين عليهم القيام به مع تقديم أي شيء. أما بالنسبة إلى الآن، قررت أن إلا أنها تنتمي في PL. أساليب معالج احملوا DTO في (DataContracts) كمدخل، التحقق من صحة رسالة طلب (الفئة الأساسية)، مصادقة (الفئة الأساسية) وأخيرا إرجاع استجابة DTO واحدة، كما يلي:

protected override void Process(TagItemRequest request, TagItemResponse response, Host host)
{
    var profile = ProfileFacade.GetProfile(host, request.Profile);
    var item = ItemFacade.GetItemId(host, request.Item);
    var tags = new List<Tag>();

    foreach (var name in request.Tags)
    {
        var tag = TagFacade.GetTag(profile, name);
        ItemFacade.TagItem(item, tag);
        tags.Add(tag);
    }

    ItemFacade.UntagItem(item, tags);
}

والآن أنا أسأل نفسي، لماذا أنا في حاجة إلى دروس اجهة 1: 1 المتعلقة بلدي الكائنات الأعمال. على سبيل المثال لدي HostFacade التي تعمل كطبقة بين hostDAO والمعالجات. مع ذلك، يحمل منطق القليل جدا، ومجرد يعالج المكالمات DAO.

public static Host GetHost(HostDTO dto)
{
   return HostDAO.GetHostByCredentials(dto.Username, dto.Password);
}

والسؤال: أنا قد دمج كذلك المعالجات واجهات، والحق

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

f.ex.

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

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

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

وثنإكس!

وجيفري

Answer 1

أولا، وأفترض أنه بحلول PL تقصد طبقة العرض، وليس بالثبات طبقة؟

عند تنفيذ تصميم التطبيق الطبقات، ينبغي أن يكون السؤال الرئيسي دائما: يمكنني استبدال تنفيذ الطبقة السفلى دون التأثير على تنفيذ طبقة (ق) أعلاه

وهذا عادة ما يكون أفضل يتضح من طبقة المثابرة. إذا قمت بالتبديل من SQL Server 2008 إلى ماي على سبيل المثال، يتغير طبقة استمرار (طبعا). ولكن تغيرات في طبقة رجال الأعمال من الضروري أيضا؟ على سبيل المثال، هل طبقة رجال الأعمال الحالات الصيد SqlException التي القيت فقط من قبل SqlClient؟ في التصميم الجيد، وطبقة رجال الأعمال لا يحتاج إلى تغييرات على الإطلاق.

وينبغي أن ينطبق نفس المبدأ على الفصل بين طبقة رجال الأعمال وطبقة العرض.

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

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

مع أطيب التحيات،

ورونالد يلدنبرج