لماذا تعتبر كائنات نقل البيانات (DTOs) نمطًا مضادًا؟
https://stackoverflow.com/questions/1440952
-
10-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
لقد سمعت مؤخرًا أشخاصًا يقولون ذلك كائنات نقل البيانات (DTOs) هي مكافحة النمط.
لماذا؟ما هي البدائل؟
المحلول
تحتوي بعض المشاريع على كافة البيانات مرتين.مرة واحدة ككائنات المجال، ومرة واحدة ككائنات نقل البيانات.
هذا الازدواجية لها تكلفة كبيرة, ، لذلك تحتاج الهندسة المعمارية إلى الحصول على فائدة كبيرة من هذا الفصل حتى تستحق العناء.
نصائح أخرى
وDTOs ليسوا على نموذج مضاد. عندما كنت ترسل بعض البيانات عبر السلك (وقل لصفحة ويب في مكالمة اياكس)، وتريد أن تتأكد من أن على الحفاظ على عرض النطاق الترددي فقط إرسال البيانات التي سيستخدمها الوجهة. أيضا، في كثير من الأحيان أنها مريحة للطبقة العرض لديها البيانات في شكل مختلف قليلا من كائن العمل الأصلي.
وأعرف أن هذا هو السؤال الموجه جافا، ولكن في لغات .NET أنواع غير معروفة والتسلسل، وLINQ تسمح DTOs التي يتم بناؤها على ذبابة، مما يقلل من الإعداد والنفقات العامة من استخدامها.
DTO النموذج المضاد في EJB 3.0 يقول:
<اقتباس فقرة>وطبيعة الوزن الثقيل من الكيان الفول في مواصفات المنظمة بتبني قبل EJB 3.0، أسفرت عن استخدام أنماط تصميم مثل نقل البيانات الكائنات (DTO). أصبح DTOs لل الكائنات الخفيفة (والذي يجب أن يكون كان الفول كيان أنفسهم في المقام الأول)، وتستخدم لإرسال البيانات عبر طبقات ... الآن EJB 3.0 المواصفات يجعل نموذج الفول الكيان نفسه وجوه جافا القديم عادي (POJO). مع هذا النموذج POJO الجديد، سوف لا تعد بحاجة لخلق DTO لكل كيان أو مجموعة من الكيانات ... وإذا كنت ترغب في إرسال الكيانات EJB 3.0 عبر الطبقة جعلها فقط تنفيذ java.io.Serialiazable
وأنا لا أعتقد DTOs تشكل نموذج مضاد في حد ذاته، ولكن هناك انتي باترن المرتبطة استخدام DTOs. بيل Dudney يشير إلى انفجار DTO كمثال:
http://www.softwaresummit.com/2003/speakers/DudneyJ2EEAntiPatterns.pdf
وهناك أيضا عدد من الانتهاكات من DTOs المذكورة هنا:
HTTP: // anirudhvyas.com/root/2008/04/19/abuses-of-dto-pattern-in-java-world/
وأنها نشأت بسبب ثلاثة أنظمة الطبقة (وعادة ما تستخدم EJB عن التكنولوجيا) كوسيلة لتمرير البيانات بين الطبقات. معظم أنظمة جافا الحديثة على أساس أطر مثل الربيع إلقاء نظرة بديل مبسطة باستخدام POJOs ككائنات المجال (في كثير من الأحيان المشروح مع النقابة الخ ...) في مستوى واحد ... استخدام DTOs هنا لا لزوم لها.
والأصوليون OO يقول أن DTO هو نموذج مضاد لكائنات تصبح تمثيلات جدول البيانات بدلا من كائنات المجال الحقيقي.
ويعتبر البعض DTOs مضاد للنمط بسبب الانتهاكات الممكنة. كنت كثيرا ما تستخدم عندما لا ينبغي أن يكون / لا تحتاج أن تكون.
إذا كنت بناء نظام توزيع، ثم DTOs هي بالتأكيد ليست نمط المضادة. ليس الجميع سوف تتطور في هذا المعنى، ولكن إذا كان لديك (على سبيل المثال) التطبيق الاجتماعي المفتوح تشغيل كل من جافا سكريبت.
ووسيتم نشر حمولة من البيانات إلى API الخاصة بك. ثم يتم إلغاء تسلسل ذلك في شكل ما من وجوه، وعادة كائن DTO / طلب. ومن ثم يمكن التحقق من صحة ذلك للتأكد من البيانات المدخلة غير صحيحة قبل أن يتم تحويلها إلى كائن النموذج.
في رأيي، هو ينظر إليه على أنه نموذج مضاد لأنه سوء استخدامها. إذا كنت لا بناء نظام توزيع، وهناك احتمالات كنت لا حاجة إليها.
وDTO يصبح ضرورة وليس نمط ANTI عندما يكون لديك كل ما تبذلونه من نطاق الكائنات كائنات الحمل يرتبط بفارغ الصبر.
إذا كنت لا تجعل DTOs، سيكون لديك الأجسام نقل غير الضرورية من طبقة رجال الأعمال لعميل / طبقة الويب الخاص بك.
للحد من النفقات العامة لهذه الحالة، وليس نقل DTOs.
نية أ كائن نقل البيانات هو تخزين البيانات من مصادر مختلفة ثم نقلها إلى قاعدة بيانات (أو الواجهة البعيدة) ذات مرة.
لكن، نمط DTO ينتهك مبدأ المسؤولية الفردية, ، نظرًا لأن DTO لا يقوم بتخزين البيانات فحسب، بل ينقلها أيضًا من أو إلى قاعدة البيانات/الواجهة.
إن الحاجة إلى فصل كائنات البيانات عن كائنات الأعمال ليست نمطًا مضادًا، حيث أنه من المحتمل أن يكون ذلك مطلوبًا فصل طبقة قاعدة البيانات على أي حال.
بدلاً من DTOs، يجب عليك استخدام أنماط التجميع والمستودع، التي تفصل بين مجموعة الكائنات (إجمالي) ونقل البيانات (مخزن).
لنقل مجموعة من الكائنات، يمكنك استخدام وحدة العمل النمط الذي يحتوي على مجموعة من المستودعات وسياق المعاملة؛من أجل نقل كل كائن في المجموع بشكل منفصل ضمن المعاملة.
السؤال لا ينبغي أن يكون "لماذا" بل ""متى".
بالتأكيد هو مكافحة النمط عندما تكون النتيجة الوحيدة لاستخدامه هي التكلفة الأعلى - وقت التشغيل أو الصيانة.لقد عملت في مشاريع تحتوي على مئات من DTOs المتطابقة مع فئات كيان قاعدة البيانات.في كل مرة تريد فيها إضافة حقل واحد تعلن عنه لإضافة معرف مثل أربع مرات - إلى DTO، إلى الكيان، إلى التحويل من DTO إلى فئات المجال أو الكيانات، التحويل العكسي، ...لقد نسيت بعض الأماكن وأصبحت البيانات غير متناسقة.
إنه ليس مضادًا للنمط عندما تحتاج حقًا إلى تمثيل مختلف لفئات المجال - أكثر استواءً، أكثر ثراءً، أكثر ضيقًا، ...
أنا شخصياً أبدأ بفئة المجال وأقوم بتمريرها، مع التحقق المناسب في الأماكن الصحيحة.يمكنني إضافة تعليقات توضيحية و/أو إضافة بعض الفئات "المساعدة" لإجراء التعيينات وقاعدة البيانات وتنسيقات التسلسل مثل JSON أو XML ...يمكنني دائمًا تقسيم الفصل إلى فصلين إذا شعرت بالحاجة.
يتعلق الأمر بوجهة نظرك - أفضل النظر إلى كائن المجال ككائن واحد يلعب أدوارًا مختلفة، بدلاً من كائنات متعددة تم إنشاؤها من بعضها البعض.إذا كان الدور الوحيد للكائن هو نقل البيانات، فهو DTO.
وأعتقد أن الناس يعني أنه يمكن أن يكون نموذج مضاد إذا قمت بتطبيق كافة الكائنات البعيدة كما DTOs. A DTO لا يعدو مجرد مجموعة من الصفات وإذا كان لديك أشياء كبيرة سوف تقوم بنقل دائما كل الصفات حتى لو كنت لا تحتاج أو استخدامها. وفي الحالة الأخيرة تفضل استخدام نمط الوكيل.
