البادئة DTO / POCOS - اصطلاحات التسمية؟

Question

سؤال بسيط حقًا، كنت أرغب في معرفة اصطلاحات التسمية التي يضعها أي شخص هناك DTO/POCOS ....

لم أكن أرغب حقًا في استخدام بادئة مثل التدوين الهنغاري ..لقد ابتعدت عن ذلك!.

لكن تسمية dtos الخاصة بي تتعارض مع أسماء الكائنات التي تم إرجاعها فعليًا وعلى الرغم من وجودها في مساحة اسم مختلفة إلا أنها لا تزال مربكة بعض الشيء.

كنت أتساءل ما هي اصطلاحات التسمية التي ينطبق عليها أي شخص

على سبيل المثال، يُسمى كائن العميل الخاص بي "العميل".

وأقوم بإجراء رسم خرائط لـ dto ...وهو العميل..كنت أفكر في DtoCustomer ..

غير متأكد

أي واحد ؟

Answer 1

وأنا أفضل أن تستخدم فضاء الأسماء لهذا الغرض. استخدام الأسماء المستعارة مساحة لهذا يجعله أكثر وضوحا.

وهذا من شأنه جعل رمز يشبه:

Customer myCustomer = new Customer();
Dto.Customer dtoCustomer = ....;

إذا أعمل تماما في طبقة DTO، ما زلت يمكن أن تعمل مع "العميل" في هذه المرحلة.

Answer 2

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

• CustomerHeader
• تفاصيل العميل
• العملاء مع الطلبات الأخيرة
• العميل والفاتورة

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

Answer 3

وأنا أحب CustomerDto أكثر من DtoCustomer. أحب أن يكون لهم مرتبة بجانب بعضها البعض.

ولكن هل يمكن تسمية أيضا تعتمد على استخدام وDTO. على سبيل المثال في MVC ASP.NET أنا في كثير من الأحيان استدعاء DTO التي يتم إرسالها إلى وجهة نظر لCustomerViewModel.

Answer 4

وأنا عادة إلحاق DTO في مثل هذه الحالات.