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

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 ни в коем случае не является единственным шаблоном проектирования для Интернета, но он полезен.

По моему мнению, принятие только буквы «М» принесет дивиденды, даже если вы не можете / не хотите использовать «V» или «C».

Answer 3

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

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

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

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

Появятся новые концепции, которые нужно понять и экспериментируйте с такими вещами, как:

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

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

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

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

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

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

Answer 4

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

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