Лучше создавать классовые модели или придерживаться универсального класса утилит базы данных?

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 или бесплатное электронное учебное пособие , и тогда вы сможете лучше судить, в каком направлении следует идти. 1011 *

Answer 2

Подход, который вы обсуждаете, многими считается хорошим, включая меня! Изучение этого подхода потребует некоторых усилий, но не позволяйте этому оттолкнуть вас!

А как насчет простого небольшого проекта с LINQ to SQL ? Возможно, найдите хороший справочный проект на коде Google и изучите, как другие работали с ним.

Это простой инструмент, который позволит вам ознакомиться с некоторыми проблемами, возникающими при сопоставлении объектов с базами данных.

После этого вы сможете почувствовать это и решить, стоит ли это кривой обучения.

Появятся новые концепции для понимания и экспериментов с такими вещами, как:

• Единица работы : Когда вы выполняете Сохранить, Удалить и т. Д., ORM имеет тенденцию не делать это немедленно, в то время как DAL на основе набора записей будет. Это может быть удивительно, поэтому вам нужно немного узнать об этом. Прочтите шаблон Единица работы , чтобы понять это.
• Массовые операции - проблема с OR / M. Считыватель данных может эффективно перебирать тысячи строк, но с ORM вы должны быть осторожны при работе с большими пакетами объектов. Опять один, чтобы читать дальше.
• Ассоциации кажутся великолепными, когда могут делать такие вещи, как customer.Orders.Count, но они также являются причиной многих проблем. Вам нужно будет найти некоторые безопасные методы, которым нужно следовать при работе с ассоциациями.

... чтобы назвать несколько.

Для начала, не беспокойтесь о наследовании и прочем, просто начните с простых и имейте простые сущности, которые отображаются в таблицы.

Попробуйте использовать их так же, как и существующий DAL. Тогда начните экспериментировать с ассоциациями.

Тогда, возможно, попробуйте добавить больше поведения в ваши сущности. Если вам это нравится, и вы чувствуете, что вам нужно больше возможностей, попробуйте более функциональный ORM, например Lightspeed или NHibernate .

Надеюсь, это поможет!

Answer 3

MVC ни в коем случае не является единственным шаблоном дизайна для Интернета, но он полезен.

Принятие только буквы "M" принесет дивиденды, на мой взгляд, даже если вы не можете / не будете принимать "V" или "C".

Answer 4

Мне кажется, вы пытаетесь сделать то, что LINQ уже может сделать для вас. Если вы застряли в старом фреймворке, в котором вы не можете его использовать, я могу предложить вам использовать Subconic (http://subsonicproject.com/) вместо того, чтобы вручную создавать все эти объекты модели вручную.

У меня был проект, в котором я находился в подобном затруднительном положении и перешел на дозвуковую половину с фантастическими результатами. Более быстрая разработка и НАМНОГО проще для чтения / использования кода.