سؤال العمارة OO / DTO

Question

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

هل سيكون من الأفضل إرسال كائن الشخص بأكمله إلى المحاسب ، أو إنشاء كائن جديد persondata فقط للاحتفاظ بالبيانات وإرسال ذلك إلى المحاسب OBJ؟

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

Answer 1

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

Answer 2

كما ذكر الآخرون ، لا توجد نقطة حقيقية في استخدام DTOs إلا إذا لم يكن هناك نقل معني ... :)

الحل الذي أقترحه ، سيكون التخلص من الكائن الذي تم نقله إليه Accountant إلى واجهة IAccountee و لدي Person قم بتنفيذها ... لست على دراية بـ C# (من ملف التعريف الخاص بك ، لقد استنتجت أن لغتك المفضلة :)) ، ولكن من المحتمل أن يوجهك إلى الاتجاه الصحيح:

class Accountant {
    //....
    public void performAction(IAccountee target) 
    {

    }
}
interface IAccountee
{
    string Name
    {
        get;
    }
    int Salary
    {
        get;
        set;
    }
}

class Person : IAccountee
{
    //implementation here, as well as some stuff specific to Person
}

في الأساس ، هذا هو د في صلب :) ... إنه مرن ونظيف ويتجنب أيضًا مشاركة المعلومات غير الضرورية من Person مع Accountant ...

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

امل ان يساعد ... ؛)

Answer 3

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

ولكن بعد ذلك ، مثل هذا مثالي للغاية ، لذلك قد يكون من الأفضل القيام بذلك بطريقة أخرى ...

Answer 4

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

Answer 5

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