طبقة الوصول إلى البيانات - فئة التصميم حيث يجب أن تكون مسؤولية إنشاء الحفظ

Question

أقوم بتصميم طبقة الوصول إلى البيانات باستخدام ADO.NET 2.0 وC# وSql Server 2005.كثيرًا ما أتشاجر مع عقلي حول مكان إجراء تلك المكالمات. أي طريقة مما يلي يجب أن أتبعها للحصول على كود قوي يمكن صيانته.

طريقة 1

Public Class Company
{

public string CompanyId
{get;set;}

public string CompanyAddress
{get;set;}

public bool Create()
{
}

public bool Update()
{
}

public bool Delete()
{
}

}

الطريقة 2

Public Class Company
{

public string CompanyId
{get;set;}

public string CompanyAddress
{get;set;}
}

وسأستخدم فئة أخرى كما هو موضح أدناه للوصول إلى البيانات الأساسية.مثل أدناه

Public Class CompanyRepository
{

public Company CreateCompany(string companyId,string companyDescription)
{
}

public bool UpdateCompany(Company updateCompany)
{
}

public bool DeleteCompany(string companyId)
{
}

public List<Company> FindById(string id)
{
}


}

Answer 1

اذهب مع الطريقة 2. ليست مسؤولية فئة الشركة القراءة/الكتابة من مصدر البيانات (مبدأ المسؤولية الواحدة).ومع ذلك، أود أن أذهب إلى أبعد من إنشاء ICompanyRepository الواجهة ثم إنشاء ملف CompanyRepository تنفيذ للواجهة.بهذه الطريقة يمكنك إدخال ICompanyRepository في الفئة التي تحتاج إلى حفظ/استرداد معلومات الشركة.كما أنه يتيح اختبارًا أسهل للوحدة والقدرة على إنشاء تطبيق مختلف في المستقبل (التبديل من قاعدة البيانات إلى ملفات XML أو أي شيء آخر).

Answer 2

إذا اتبعت مبدأ فصل المخاوف ، فستنتقل إلى الطريقة الثانية.

يساعد وجود مسؤوليات مختلفة في فئات مختلفة في إنشاء كود قابل للاختبار ويمكن صيانته.

ينتج عن هذا أيضًا فئات أصغر وأكثر تماسكًا يسهل كتابتها وتوضيح أسبابها والتحقق من صحتها.

كملاحظة ، يمكنك استخدام ORM بدلاً من صياغة الوصول إلى البيانات يدويًاطبقة.

Answer 3

سأدافع عن الخيار الثاني ، السبب

• أولاً ، تقوم بإنشاء رمز الرمز العام الخاص بك
• بعد وضع الصندوق لرمز الرمز العام الخاص بك

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