كيفية التعامل مع DTOs وتنظيمها لسياقات مختلفة؟

Question

عند استخدام DTOs البسيطة في سيناريوهات مختلفة، كثيرًا ما أواجه نفس النوع من المشكلات وكنت أتساءل دائمًا عما إذا كانت هناك طريقة أفضل للتعامل معها.

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

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

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

• لدي انفجار صفي مع عدد كبير من فئات DTO
• أجد صعوبة كبيرة في الخروج بأسماء مختلفة لنفس الشيء مثل AssetDtoForGridInTheOverviewScreenInTheUpperPaneAboveTheSplitter, ناهيك عن صيانتها لاحقًا
• كثيرا ما أكرر نفسي في طرق التحويل، لأن هناك خصائص يتم استخدامها معظم من DTOs ولكن ليس من قبل الجميع منهم (وبالتالي لا يمكنني وضعهم في أي فئة فائقة وإعادة استخدام منطق التحويل)

التكنولوجيا التي أستخدمها هي ASP.NET SOAP WebServices وC# 3.5، لكنني أعتقد بطريقة أو بأخرى أن هذه قد تكون مشكلة لا تتعلق باللغة.أي أفكار هي موضع ترحيب ..

Answer 1

هذه مشكلة معروفة في DTOs.لقد تم وصفه في هذا المتوسط المادة على MSDN.إعادة صياغة:يعد DTO هو نمط الوصول إلى البيانات الأكثر تنوعًا، ولكنه يتطلب أيضًا الكثير من العمل.

يمكنك معالجة بعض المشكلات التي تواجهك في رسم الخرائط باستخدام رسم الخرائط المستند إلى الاصطلاحات، مثل AutoMapper.

عندما يتعلق الأمر بالانفجار الطبقي، هل من الممكن أنك تستخدم هياكل بيانات مسطحة جدًا؟

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

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

Answer 2

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

مع ظهور .NET 3.5، يمكنك اختيار تنفيذ بعض عمليات DTO الأساسية والأكثر دقة واستبدال ViewModel الخاص بك بنوع مجهول يمكنك إنشاؤه ديناميكيًا من DTO الخاص بك.لقد وجدت أن هذا حل مرن جدًا.

فيما يتعلق باصطلاحات التسمية الخاصة بك، ربما يكون من المفيد تجميع DTO الخاص بك في سيناريوهات ووضعها في مساحة اسم مقابلة.على سبيل المثال Solution.AssetManagement.Asset و Solution.AssetReporting.Asset