هل من الأفضل إنشاء فئات نموذجية أم الالتزام بفئة الأداة المساعدة لقاعدة البيانات العامة؟

Question

لدينا فئة أدوات مساعدة بسيطة داخليًا لاستدعاءات قاعدة البيانات الخاصة بنا (غلاف خفيف حول ADO.NET)، لكنني أفكر في إنشاء فئات لكل قاعدة بيانات/كائن.هل سيكون من الذكاء القيام بذلك أم أنه سيستفيد فقط إذا كنا نستخدم إطار عمل MVC الكامل لـ ASP.NET؟

لذلك لدينا هذا:

SQLWrapper.GetRecordset(connstr-alias, sql-statement, parameters);
SQLWrapper.GetDataset(connstr-alias, sql-statement, parameters);
SQLWrapper.Execute(connstr-alias, sql-statement, parameters);

أفكر في القيام بذلك:

Person p = Person.get(id);
p.fname = "jon";
p.lname = "smith";
p.Save();

أو لرقم قياسي جديد -

Person p = new Person();
p.fname = "Jon";
p.lname = "Smith";
p.Save();
p.Delete();

هل سيكون هذا ذكاء أم سيكون مبالغة؟أستطيع أن أرى فائدة إعادة الاستخدام وتغيير قاعدة البيانات والصيانة/سهولة القراءة.

Answer 1

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

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

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

Answer 2

لا يعد MVC بأي حال من الأحوال نمط التصميم الوحيد للويب، ولكنه نمط مفيد.

إن اعتماد حرف "M" فقط سيؤتي ثماره، في رأيي، حتى لو لم تتمكن/لن تعتمد "V" أو "C".

Answer 3

يعتبر النهج الذي تناقشه جيدًا من قبل العديد من الأشخاص، بما فيهم أنا!سيتطلب تعلم هذا النهج بعض الجهد، لكن لا تدع ذلك يحبطك!

ماذا عن مجرد محاولة أ مشروع صغير مع LINQ إلى SQL؟ربما تجد أ مشروع مرجعي لطيف على رمز جوجل, ، ودراسة كيفية عمل الآخرين معها.

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

ستتمكن بعد ذلك من ذلك التعود على ذلك, ، وقرر ما إذا كان الأمر يستحق منحنى التعلم.

سيكون هناك مفاهيم جديدة لفهمها وتجربة أشياء مثل:

• وحدة العمل:عند تنفيذ الحفظ والحذف وما إلى ذلك، يميل ORM إلى عدم القيام بذلك على الفور، في حين أن DAL المستند إلى مجموعة السجلات سيفعل ذلك.قد يكون هذا مفاجئًا لذا ستحتاج إلى معرفة القليل عن ذلك.إقرأ على وحدة نمط العمل للحصول على فهم لهذا.
• العمليات السائبة هي مشكلة مع OR/M.يمكن لقارئ البيانات التكرار بكفاءة عبر آلاف الصفوف، ولكن مع ORM يجب عليك توخي الحذر عند العمل مع مجموعات كبيرة من الكائنات.مرة أخرى، واحدة للقراءة.
• ذات الصلة تبدو رائعة عندما تستطيع فعل أشياء مثل customer.Orders.Count ولكنها أيضًا سبب للعديد من المشاكل.ستحتاج إلى العثور على بعض الممارسات الآمنة التي يجب اتباعها عند العمل مع الجمعيات.

...على سبيل المثال لا الحصر.

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

حاول استخدامها بنفس الطريقة التي تستخدم بها DAL الموجود لديك.ثم ابدأ بتجربة الارتباطات.

ثم ربما حاول وضع المزيد من السلوك في كياناتك.إذا بدأت في الإعجاب بهذا، وشعرت أنك بحاجة إلى المزيد من الميزات، ففكر في تجربة ORM أكثر ثراءً بالميزات سرعة الضوء أو السبات.

أتمنى أن يساعدك هذا!

Answer 4

بالنسبة لي، يبدو أنك تحاول أن تفعل ما يمكن أن يفعله LINQ لك بالفعل.إذا كنت عالقًا في إطار عمل قديم لا يمكنك استخدامه فيه، فقد أقترح عليك استخدام Subconic (http://subsonicproject.com/) بدلاً من الاضطرار إلى إنشاء كل كائنات النماذج هذه يدويًا.

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