كيفية تصميم كائنات نقل البيانات في طبقة منطق الأعمال

Question

في

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

أنا أستخدم llbgen لتوليد طبقة الوصول إلى البيانات (باستخدام SQL Server 2008). الهدف هو بناء طبقة منطق الأعمال التي تقوم بعمل تطبيق الويب من تفاصيل DAL، وبالطبع، لتوفير مستوى إضافي من التحقق من الصحة بعد DAL. أيضا، بقدر ما أستطيع أن أقول الآن، ستكون خدمة الويب غلافا رفيعيا على BLL.

دال، بالطبع، لديها مجموعة من كائنات الكيان الخاصة بها، على سبيل المثال، والجكانات، والتجول، وما إلى ذلك. ومع ذلك، لا أريد أن يتمكن طبقة العرض التقديمي من الوصول إلى هذه الكائنات مباشرة، لأنها تحتوي على طرق محددة DAL والجمعية خاصة ب DAL وهلم جرا. لذلك، فإن الفكرة هي إنشاء كائنات نقل البيانات (DTO). الفكرة هي أن هذه ستكون، أساسا، كائنات صافية C # /. قول كل مجالات، على سبيل المثال، عميل Custillentity هي في الواقع عميل جدول قاعدة البيانات ولكن لا شيء من الأشياء الأخرى، باستثناء بعض الخصائص المحفوظة / ISDirty. لذلك، سيكون هناك CustomerDTo، ProductDto، وما إلى ذلك، أفترض أن هذه ستورث من فئة DTO الأساسية. أعتقد أنه يمكنني توليد هذه مع بعض القالب ل Llbgen، لكنني لست متأكدا من ذلك حتى الآن.

لذلك، فإن الفكرة هي أن BLL ستقدم وظائفه من خلال قبول وإعادة كائنات DTO هذه وإعادة. أعتقد أن خدمة الويب ستتعامل مع تحويل هذه الكائنات إلى XML للأطراف الثالثة التي تستخدمها، قد لا يستخدم الكثيرون .NET (أيضا، بعض الأشياء ستكون نصية نصية ممكنة من مكالمات AJAX على تطبيق الويب، باستخدام JSON).

لست متأكدا من أفضل طريقة لتصميم هذا والضبط كيفية المضي قدما. فيما يلي بعض المشكلات:

1) كيف يجب التعرض لهذا للعملاء (الطبقة العرضية وإلى رمز خدمة الويب)

كنت أفكر في أن هناك فئة عامة واحدة لها هذه الأساليب، ستكون كل مكالمة عملية ذرية:

insertdto، uppectedto، deletedto، getproducts، getproductbycustomer، وما إلى ذلك ...

ثم سيقوم العملاء باستدعاء هذه الأساليب وتمرير الحجج المناسبة، عادة DTO.

هل هذا نهج جيد أو قابل للتطبيق؟

2) ماذا أعود من هذه الأساليب؟ من الواضح أن نوع الطرق الحصول على / جلب سيعود DTO. ولكن ماذا عن إدراج؟ جزء من التوقيع يمكن أن يكون:

InsertDTO(DTO dto)

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

خيار واحد اعتقدت أنه كان فئة نتيجة:

class Result
{
    public Exception Error {get; set;}
    public DTO AffectedObject {get; set;}
}

لذلك، عند إدراج، سيحصل DTTO على معرف يحصل على معرف (مثل CustomerDto.Customerid) مجموعة الممتلكات ثم ضع كائن هذا النتيجة. سيعرف العميل إذا كان هناك خطأ إذا كان النتيجة.

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

حسنا، آمل أن يكون هذا ليس صحيحا للغاية ولكن أريد أن أكون واضحا.

Answer 1

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

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

• استعمال ref على العقد (ليست جميلة جدا)
• إرجاع كائن (محدث) - أي public DTO SomeOperation(DTO item);
• إرجاع فقط معلومات الهوية المحدثة (المفتاح الأولية / الطابع الزمني / إلخ)

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

Answer 2

q1: يمكنك التفكير في أنواع COMPOSITE عقد بيانات WCF الخاصة بك ك DTOS لحل هذه المشكلة. بهذه الطريقة أن طبقة UI الخاصة بك لديها فقط الوصول إلى خصائص DataContract الخاصة ب Datamember. ستكون العمليات الذرية الخاصة بك هي الأساليب التي يتعرضها واجهة WCF الخاصة بك.

Q2: تكوين عقود بيانات الاستجابة الخاصة بك لإرجاع نوع مخصص جديد مع مفاتيحك الأساسية وما إلى ذلك ... يمكن أيضا تكوين WCF لاستثناءات الفقاعات مرة أخرى إلى UI.