كائن Clr القديم عادي VS كائن نقل البيانات
https://stackoverflow.com/questions/725348
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
Poco = كائن CLR القديم العادي (أو أفضل: فئة)
DTO = كائن نقل البيانات
في هذا بريد هناك فرق، ولكن بصراحة معظم المدونات التي قرأت وصفها وصف poco بالطريقة المحددة DTO: DTOS هي حاويات بيانات بسيطة تستخدم لتحريك البيانات بين طبقات التطبيق.
هي poco و dto نفس الشيء؟
المحلول
بوكو يتبع قواعد OOP. يجب (ولكن ليس لديك) لديك حالة و سلوك. Poco يأتي من Pojo، صاغه مارتن فاولر [الحكايات هنا]. استخدم مصطلح POJO كوسيلة لجعله أكثر إثارة لرفض تطبيقات EJB الثقيلة الإطار. يجب استخدام Poco في نفس السياق في .NET. لا تدع الأطر يملي تصميم كائنك.
غرض DTO الوحيد هو نقل الدولة، ويجب عدم وجود سلوك. انظر مارتن فاولر شرح DTO مثال على استخدام هذا النمط.
إليك الفرق: بوكو يصف نهج للبرمجة (برمجة وجهة نظر ذات طراز قديم جيدة)، حيث DTO هو نمط يستخدم "نقل البيانات" باستخدام الكائنات.
بينما يمكنك علاج Pocos مثل DTOS، فإنك تدير مخاطر إنشاء نموذج النفقات الفقراء إذا فعلت ذلك. بالإضافة إلى ذلك، هناك عدم تطابق في الهيكل، حيث يجب تصميم DTOS لنقل البيانات، وليس لتمثيل الهيكل الحقيقي لمجال الأعمال. نتيجة هذه هي أن DTOS تميل إلى أن تكون أكثر شقة من مجالك الفعلي.
في مجال أي تعقيد معقول، كنت دائما أفضل حالا خارج إنشاء Pocos المجال منفصلة وترجمتها إلى DTOS. DDD (تصميم مدفوعة) يحدد طبقة مكافحة الفساد (رابط آخر هنا, ، ولكن أفضل شيء للقيام به هو شراء الكتاب)، وهو هيكل جيد يجعل الفصل واضحا.
نصائح أخرى
ربما يكون من الضروري بالنسبة لي أن أسهم منذ أن ذكرت موقعي بالفعل في مقال مدونتي، لكن الفقرة الأخيرة من هذا النوع من المادة من الأمور:
لذلك، في الختام، تعلم أن تحب حبيبو، وتأكد من أنك لا تنشر أي معلومات مضللة حول كونها نفس الشيء مثل DTO. DTOS عبوات بيانات بسيطة تستخدم لتحريك البيانات بين طبقات التطبيق. تعتبر Pocos كائنات تجارية كاملة مع المتطلبات الواحدة التي يتم إجراؤها. أخيرا، إذا لم تقم بفحص كتاب جيمي نيلسون بعد، استلامه من مداخن الجامعة المحلية الخاصة بك. لديها أمثلة في C # وهي قراءة رائعة.
راجع للشغل، باتريك قرأت بوكو كقالة نمط حياة، وأنا أتفق تماما، وهذا مقالة رائعة. إنه في الواقع قسم من كتاب جيمي نيلسون الذي أوصت به. لم يكن لدي أي فكرة أنه كان متاحا عبر الإنترنت. كتابه هو أفضل مصدر للمعلومات التي وجدتها على Poco / DTO / مستودع / ممارسات تطوير DDD الأخرى.
Poco هو ببساطة كائن لا يتخذ اعتمادا على إطار خارجي. إنه سهل.
ما إذا كان لدى Poco سلوكا أم لا غير مادي.
قد يكون DTU بوكو ككائن مجال (الذي عادة ما يكون غنيا بالسلوك).
عادة ما تكون DTOS أكثر عرضة لاتخاذ تبعيات على الأطر الخارجية (على سبيل المثال، سمات) لأغراض التسلسل كما هو مخرج عادة في حدود النظام.
في بنية أسلوب البصل النموذجي (غالبا ما تستخدم ضمن نهج DDD على نطاق واسع) وضعت طبقة المجال في المركز، وبالتالي يجب ألا يكون كائناتها، في هذه المرحلة، تعاضات خارج تلك الطبقة.
كتبت مقالا لهذا الموضوع: DTO VS قيمة كائن VS Poco.
بالمختصر:
- DTO! = كائن القيمة
- DTO ⊂ Poco.
- قيمة كائن ⊂ Poco
أعتقد أن DTO يمكن أن يكون بوكو. DTO أكثر حول استخدام الكائن أثناء وجود بوكو أكثر من نمط الكائن (فصل من المفاهيم المعمارية).
مثال واحد حيث يكون Poco شيء مختلف عن DTO هو عندما تتحدث عن Poco's Inside داخل نموذج النطاق الخاص بك / عمل النطاق الخاص بك، وهو تمثيل OO لطيف لمجال المشكلات الخاصة بك. يمكنك استخدام Poco's في جميع أنحاء التطبيق بأكمله، ولكن هذا يمكن أن يكون له بعض التأثيرات الجانبية غير المرغوب فيها مثل تسرب المعرفة. DTO هي على سبيل المثال المستخدمة من طبقة الخدمة التي يتصل بها UI معها، والمنتدى DTO تمثيل ثابت للبيانات، ويتم استخدامها فقط لتزويد واجهة المستخدم مع البيانات، وتقليل التغييرات مرة أخرى إلى طبقة الخدمة. طبقة الخدمة مسؤولة عن تعيين طرق DTO لكائنات مجال Poco.
تحديث مارتن فاولر قال أن هذا النهج هو طريق ثقيل يجب أن تأخذ، ويجب اتخاذها إلا إذا كان هناك عدم تطابق كبير بين طبقة المجال وواجهة المستخدم.
حالة الاستخدام الأساسي ل DTO موجودة في إرجاع البيانات من خدمة ويب. في هذه الحالة، تعادل Poco و DTO. ستتم إزالة أي سلوك في Poco عند إرجاعها من خدمة ويب، لذلك لا يهم حقا ما إذا كان لديه سلوك أم لا.
هنا هي القاعدة العامة: DTO == الشر والمؤشر البرمجيات فوق الهندسة. بوكو == جيد. لقد دمرت أنماط "المؤسسة" أدمغة الكثير من الناس في عالم Java EE. من فضلك لا تكرر الخطأ في أرض .NET.
يتم استخدام فصول DTO لتسلسل / تخليص البيانات من مصادر مختلفة. عندما تريد استخدام كائن من مصدر، لا يهم المصدر الخارجي هو: الخدمة، الملف، قاعدة البيانات وما إلى ذلك. قد ترغب فقط في استخدام جزء من ذلك ولكنك تريد طريقة سهلة لتحمل تلك البيانات إلى هدف. بعد ذلك نسخ البيانات إلى xmodel تريد استخدامها. Serializer هي تقنية جميلة لتحميل كائنات DTO. لماذا ا؟ تحتاج فقط إلى وظيفة واحدة لتحميل (Deserialize) الكائن.
TL؛ DR:
تصف DTO نمط نقل الدولة. بوكو لا يصف أي شيء. إنها طريقة أخرى لقول "كائن" في OOP. يأتي من Pojo (Java)، الذي صاغه Martin Fowler الذي يصفه حرفيا باسم Fancier باسم "كائن" لأن "كائن" ليس مثير للغاية.
DTO هو نمط كائن يستخدم لنقل الحالة بين طبقات القلق. يمكن أن يكون لديهم سلوك (أي يمكن أن يكون من الناحية الفنية بوكو) طالما أن هذا السلوك لا يتحول الحالة. على سبيل المثال، قد يكون لها طريقة تستسلم نفسها.
Poco هو كائن عادي، ولكن المقصود عن طريق "سهل" هو أنه ليس خاصا. هذا يعني أنه كائن CLR بدون نمط ضمني لذلك. مصطلح عام. لم يتم عملها للعمل مع بعض الإطار الآخر. لذلك إذا كان لدى Poco الخاص بك [JsonProperty] أو ef decorations في جميع أنحاء العالم خصائص، على سبيل المثال، ثم سأجادل بأنه ليس بوكو.
هنا بعض الأمثلة على أنواع مختلفة من أنماط الكائنات للمقارنة:
- عرض النموذج: تستخدم لنموذج البيانات للحصول على عرض. عادة ما يكون لديه شروح بيانات لمساعدة الربط والتحقق من الصحة. في MVVM، تعمل أيضا كوحدة تحكم. انها أكثر من DTO
- كائن القيمة: تستخدم لتمثيل القيم
- إجمالي الجذر: تستخدم لإدارة الدولة والثبات
- معالجات: تستخدم للرد على الحدث / الرسالة
- صفات: تستخدم كزينة للتعامل مع المخاوف الشاملة
- خدمة: تستخدم لأداء المهام المعقدة
- مراقب: تستخدم للتحكم في تدفق الطلبات والردود
- مصنع: تستخدم لتكوين و / أو تجميع الكائنات المعقدة للاستخدام عندما يكون منشئ ليس جيدا بما فيه الكفاية. تستخدم أيضا لاتخاذ القرارات التي تحتاج إلى إنشاء الكائنات عند وقت التشغيل.
- مستودع / داو: تستخدم للوصول إلى البيانات
هذه كلها كائنات فقط، ولكن لاحظ أن معظمهم مرتبطون بشكل عام بنمط. حتى تتمكن من الاتصال بهم "كائنات" أو قد تكون أكثر تحديدا حول نيتها واتصل بها بما هو عليه. هذا هو أيضا السبب في أن لدينا أنماط التصميم؛ لوصف المفاهيم المعقدة في عدد قليل من الأعمال. DTO هو نمط. جذر إجمالي هو نمط، عرض النموذج هو نمط (مثل MVC & MVVM). بوكو ليس نمطا.
بوكو لا يصف نمطا. إنها طريقة مختلفة للإشارة إلى الفصول الدراسية / الكائنات في OOP. فكر في الأمر بمفهوم مجردة؛ يمكن أن يكونوا يشيرون إلى أي شيء. IMO، هناك علاقة أحادية الاتجاه لأنها بمجرد أن يصل كائن إلى النقطة حيث يمكن أن تخدم فقط غرضا واحدا بشكل نظيف، لم يعد بوكو. على سبيل المثال، بمجرد تحديد فصلك مع زخارف لجعلها تعمل مع بعض الإطار، لم تعد بوكو. لذلك:
- DTO هو بوكو
- بوكو ليس DTO
- نموذج عرض هو بوكو
- بوكو ليس نموذج عرض
إن النقطة في التمييز بين الاثنين تدور حول حفظ الأنماط واضحة ومتسقة في الجهد لعدم تعبر المخاوف وتؤدي إلى اقتران ضيق. على سبيل المثال، إذا كان لديك كائن أعمال له أساليب لتحويل الحالة، ولكن تم تزيينها أيضا بجحيم مع زخارف EF للحفظ إلى SQL Server و JSONProperty بحيث يمكن إرسالها عبر نقطة نهاية API. سيكون هذا الكائن غير متسامح في التغيير، ومن المرجح أن يتعارض مع متغيرات من الممتلكات (مثل معرف المستخدم، UserPk، userkey، userguid، حيث يتم حفظ بعضها لعدم حفظ DB وغيرها من غير متسلسل JSON في نقطة النهاية API).
لذلك إذا كنت تخبرني أن هناك شيء كان DTO، فمن المحتمل أن أتأكد من أنه لم يتم استخدامه أبدا لأي شيء آخر غير متحرك الدولة. إذا أخبرتني أنه كان هناك نموذج عرض، فمن المحتمل أن أتأكد من أنه لم يتم حفظه في قاعدة بيانات. إذا أخبرتني أن شيئا ما كان نموذجا للنطاق، فمن المحتمل أن أتأكد من عدم وجود تبعيات على أي شيء خارج المجال. ولكن إذا قلت لي شيئا كان بوكو، فلن تخبرني حقا على الإطلاق.
لا تطلق عليها حتى DTOS. انهم يسمى عارضات ازياء....فترة. النماذج لا تملك سلوكا. لا أعرف من جاء بهذا المصطلح الغبي ولكن يجب أن يكون شيئا. نين هو كل ما يمكنني معرفة. فكر في نماذج الرؤية في MVC، نفس السد ** شيء، يتم استخدام الطرز لنقل الحالة بين جانب خادم الطبقات أو فوق فترة الأسلاك، فهي جميع النماذج. خصائص مع البيانات. هذه هي النماذج التي تمر ove السلك. نماذج، نماذج النماذج. هذا هو.
أتمنى أن يذهب المصطلح الغبي DTO بعيدا عن مفرداتنا.
