ما هي الطريقة الشائعة لتصميم نمط OOP (الوصول إلى البيانات)

Question

في الأصل كان هناك كائن DAL الذي استدعاه BO للحصول على معلومات ثم تم تمريره إلى واجهة المستخدم.ثم بدأت ألاحظ انخفاض التعليمات البرمجية في واجهة المستخدم وكانت هناك فئات تحكم.ما هي التوصية اللائقة.

أنا حاليا هيكلة الألغام

Public Class OrderDAL

    Private _id Integer
    Private _order as Order

    Public Function GetOrder(id as Integer) as Order

        ...return Order

    End Function

End Class

ثم لدي فئات تحكم (نفذت هذا النمط مؤخرًا)

Public Class OrderController

    Private Shared _orderDAL as new OrderDAL

    Public Shared Function GetOrder(id) As Order

        Return _orderDAL.GetOrder(id)

    End Function

End Class

ثم في طلبي

My app Sub

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

        msgbox(OrderController.GetOrder(12345).Customer.Name)

    End Sub


End app

لقد وجدت في الأصل أنه مع Shared Class لم أضطر إلى الاستمرار في إنشاء مثيل جديد لـ DAL عندما أحتاج إلى جلب البيانات

Dim _orderDAL as New OrderDal

_orderDAL.GetOrder(1234)

.....

ما هو رأيك؟

شكرًا

Answer 1

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

تتمثل الطريقة الثابتة لدعم وحدات تحكم الطلبات المختلفة، من الناحية النظرية، في إنشاء مصنع:

OrderControllerFactory.ConfiguredOrderController().GetOrder(42);

المشكلة هنا هي:ما النوع الذي يتم إرجاعه بواسطة "ConfiguredOrderController()"؟لأنه يجب أن يحتوي على طريقة "GetOrder(int id)" الثابتة - والطرق الثابتة غير مدعومة بالوراثة أو الواجهات.الحل هو عدم استخدام الأساليب الثابتة في فئة OrderController.

public interface IOrderController
{
    Order GetOrder(int Id)
}

public class OrderController: IOrderController
{
    public Order GetOrder(int Id)
    {}
}

و

public class OrderControllerFactory()
{
    public IOrderController ConfiguredOrderController()
    {}
}

وبالتالي، من المحتمل أن تكون أفضل حالًا باستخدام الأساليب غير الثابتة لوحدة التحكم.

Answer 2

أعتقد أن هناك العديد من البدائل المذكورة في هذا الكتاب الممتاز: أنماط بنية تطبيقات المؤسسات.بعض الأنماط التي قد تهمك:

• سجل نشط
• بوابة بيانات الجدول
• بوابة بيانات الصف
• مخطط البيانات

Answer 3

حسنًا، لا ينبغي أن يقوم تطبيقك بإنشاء إصدارات منفصلة من طبقة الوصول إلى البيانات، لذلك يمكنك التحكم في ذلك.من الصعب حقًا قراءة رمز Psuedo الذي نشرته.

والسؤال هو، ما هي طبقة الوصول إلى البيانات الخاصة بك، وكم هو هناك؟هذا سوف يملي عليك جزءًا جيدًا مما تفعله.إذا كنت تتابع ملفًا، فأعتقد أن ما كتبته جيد، وإذا كنت بحاجة إلى مشاركته مع وحدات تحكم أخرى في نظامك، فمن الممكن لف العنصر في مفردة (قشعريرة).

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

$.02 الخاص بي، وأنا أحتفظ بالحق في مراجعة إجابتي بمجرد رؤية مثال أفضل.

Answer 4

لا أستطيع التحدث إلى تفاصيل VB لأنني لست مطور VB، ولكن:

ما تفعله هو ممارسة جيدة راسخة، حيث تفصل طبقة واجهة المستخدم الرسومية/العرض التقديمي عن طبقة البيانات.يعد تضمين رمز التطبيق الحقيقي في أساليب حدث واجهة المستخدم الرسومية (GUI) ممارسة سيئة (للأسف أيضًا راسخة).

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

تفضل!

Answer 5

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