ما هي الطريقة الشائعة لتصميم نمط OOP (الوصول إلى البيانات)
-
02-07-2019 - |
سؤال
في الأصل كان هناك كائن 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)
.....
ما هو رأيك؟
شكرًا
المحلول
لقد استخدمت الحل الخاص بك في الماضي، والمشكلة الوحيدة التي واجهتها هي أن الأساليب "المشتركة" أو "الثابتة" لا تدعم الميراث.عندما ينمو تطبيقك، قد تحتاج إلى دعم أنواع مختلفة من "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()
{}
}
وبالتالي، من المحتمل أن تكون أفضل حالًا باستخدام الأساليب غير الثابتة لوحدة التحكم.
نصائح أخرى
أعتقد أن هناك العديد من البدائل المذكورة في هذا الكتاب الممتاز: أنماط بنية تطبيقات المؤسسات.بعض الأنماط التي قد تهمك:
حسنًا، لا ينبغي أن يقوم تطبيقك بإنشاء إصدارات منفصلة من طبقة الوصول إلى البيانات، لذلك يمكنك التحكم في ذلك.من الصعب حقًا قراءة رمز Psuedo الذي نشرته.
والسؤال هو، ما هي طبقة الوصول إلى البيانات الخاصة بك، وكم هو هناك؟هذا سوف يملي عليك جزءًا جيدًا مما تفعله.إذا كنت تتابع ملفًا، فأعتقد أن ما كتبته جيد، وإذا كنت بحاجة إلى مشاركته مع وحدات تحكم أخرى في نظامك، فمن الممكن لف العنصر في مفردة (قشعريرة).
إذا كنت تقوم بالفعل بمعالجة الطلب والرجوع إلى قاعدة البيانات، فأنا شخصياً أعتقد أن الوقت قد حان لإلقاء نظرة على ORM.ستتعامل هذه الحزم مع جوانب CRUM نيابةً عنك وتقلل من عدد العناصر التي يتعين عليك صيانتها.
$.02 الخاص بي، وأنا أحتفظ بالحق في مراجعة إجابتي بمجرد رؤية مثال أفضل.
لا أستطيع التحدث إلى تفاصيل VB لأنني لست مطور VB، ولكن:
ما تفعله هو ممارسة جيدة راسخة، حيث تفصل طبقة واجهة المستخدم الرسومية/العرض التقديمي عن طبقة البيانات.يعد تضمين رمز التطبيق الحقيقي في أساليب حدث واجهة المستخدم الرسومية (GUI) ممارسة سيئة (للأسف أيضًا راسخة).
تشبه فئة وحدة التحكم الخاصة بك فئة نمط الجسر وهي أيضًا فكرة جيدة إذا كانت كلتا الطبقتين قادرتين على تغيير شكلهما دون علم الأخرى بذلك.
تفضل!
إنها ممارسة جيدة - خاصة عندما تصل إلى نقطة حيث سيحتاج جهاز التحكم إلى القيام بأكثر من مجرد تفويض بسيط إلى DAL الأساسي.