تمرير البيانات في تطبيق NTIER

Question

كيف يمكنك تمرير البيانات إلى طبقات في تطبيق N-Tier؟ لقد حددت 3 طرق مختلفة.

أ)كائنات عامة. NET كائنات جداول بيانات عامة، Hashtables، مجموعات بيانات عامة، سلاسل، Ints، ... ثم استخدام مجموعات البيانات لملء كائنات عملك التي يتم إرسالها إلى طبقة UI.

النص البديل http://img11.imageshack.us/img11/460/generic.png.

http://dabbleboard.com/draw؟b=eiu165&i=26&c=54eef6f1ac01f03c85919518f4a24e798e57e133.

طليعة- لا توجد طبقات إضافية حاجةملاك يجب أن تعمل مع مجموعات البيانات العامة والطاولات في طبقة العمل

ب)باستخدام طبقة الكيانات التي تشير الطبقات الأخرى إليها. سيحتوي هذه الطبقة على مجموعات بيانات مكتوبة بشدة أو كائنات C القديمة العادية. ستكون الكائنات في الغالب بيانات الحاويات والمنطق القليل جدا. ستكون هذه هي نفس الكائنات المرسلة إلى طبقة UI.

نص Alt http://img8.imageshack.us/img8/6454/entities.png.

http://dabbleboard.com/draw؟b=eiu165&i=6&c=d0c2b346894a96b12bd3867f630e474a2af098fa.

طليعة- العمل مع نفس الفصول في جميع الطبقاتملاك إضافة مرجع إلى الكيانات. إلى جميع الطبقات

ج)استخدم كائنات نقل البيانات (كائنات CONATINER فقط) محددة في طبقة DataAccess. ثم استخدام هذه الكائنات لملء كائنات العمل التي يتم إرسالها إلى طبقة UI.

نص Alt http://img43.imageshack.us/img43/1236/transferp.png.

http://dabbleboard.com/draw؟b=eiuu165&i=27&c=f886efa3f9d5eb4b45ddb02361c79cdcdaec0a9b.

طليعة- لن تضطر طبقة العمل إلى العمل مع فصول عامةملاك العمل مع نوعين من الكائنات وستحتاج إلى ترطيب كائنات العمل مع كائنات النقل

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

Answer 1

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

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

Answer 2

سؤال عظيم - كما هو الحال دائما، يجب أن تكون الإجابة "ذلك".

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

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

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

Answer 3

أحب الخيار ج ولكنه يعطيني أيضا وقفة لسببين:

1. لا بد لي من نشر knowowlledge بما أن الأساليب في أماكن كثيرة جدا.
2. يجب أن تكون DTO أنها غير قابلة للتسلسل، والتي ليست فظيعة ولكنها لا تزال اعتبار.

Answer 4

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