كائنات نقل البيانات وأساليب خدمة المعاملات

Question

هل هناك أي طريقة عملية حقا لتجنب استخدام DTOS، عند تمرير البيانات من خلال طرق خدمة المعاملات المدعومة من السبات؟ وبعبارة أخرى، هي DTOS الحل الوحيد غير المخرج لتجنب مشاكل التهيئة الكسولة؟

أعتقد أن اثنين من البدائل الشائعة ل DTOS والأسباب التي لا أحبها حقا هي:

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

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

هل أنا أفتقد شيئا ما أو هي DTOS في الواقع النهج الصلب الوحيد من وجهة نظر إمكانية الصيانة؟

Answer 1

الطريقة الوحيدة لاستخدام الكيانات حقا هي استخدام شيء أكثر تطورا قليلا من OpenSessionInview. في تجربتي، يجب عليك إدارة جلسة السبات يدويا على مستوى التطبيق. لن يمنحك OpenSessionInView إلا نفس الجلسة لطلب واحد. بعد ذلك، ستحتاج إلى إعادة بناء باستمرار إلى الجلسة الحالية. ألق نظرة على التماس والمحادثات، أو تنفيذ إدارة جلسة السبات الخاصة بك. نحن حاليا إدارة جلساتنا يدويا بناء على عندما يبدأ المعالج وينتهي واستخدام AOP الربيع لتوصيل الجلسات إلى المواضيع الصحيحة في الوقت المناسب (الدورات غير آمنة، وليس مزيج جيد مع AJAX)

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

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

Answer 2

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

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

لجعل حياتك أسهل، قد تكون هناك مكتبات أو أطر يمكن أن تقوم بها تلقائيا من كائنات نموذج المجال الخاصة بك إلى كائنات نموذج العرض الخاصة بك، والظهر. في .NET، هناك إطار مفتوح المصدر يسمى Automapper حاليا في التنمية؛ لست متأكدا مما هو موجود ل Java.

Answer 3

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

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

Answer 4

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

باستخدام وجهات نظر الكيان، لا تحتاج إلى الجلسة المفتوحة في عرض Anti-Pattern، لأنه يتم تحميل الهيكل المرغوب بفارغ الصبر. نظرا لعدم وجود كائنات كيكة مشتركة، لن تكون هناك أيضا مشاكل تحميل كسول.

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

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