Лучше ли создавать классы моделей или придерживаться общего служебного класса базы данных?
-
08-06-2019 - |
Вопрос
У нас есть простой служебный класс для вызовов нашей базы данных (легкая оболочка 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();
Будет ли это разумно или будет излишним?Я вижу преимущества повторного использования, изменения базы данных и обслуживания/читаемости.
Решение
Этот вопрос загружен: дизайн, управляемый данными, или дизайн, управляемый предметной областью.Для любого приложения с хорошим поведением следует отдавать предпочтение проектированию, ориентированному на предметную область.Приложения для создания отчетов или служебные приложения, как правило, работают лучше (или быстрее разрабатываются) при проектировании, основанном на данных.
Вы спрашиваете: «Должна ли моя компания внести фундаментальные изменения в то, как мы разрабатываем наш код».Как помешанный на предметной области, моя инстинктивная реакция — кричать да.Однако, учитывая простоту вашего вопроса, я не уверен, что вы полностью понимаете масштаб предлагаемых вами изменений.Я думаю, вам следует больше поговорить об этом со своей командой.
Возьмите какую-нибудь литературу, например DDD Эвана книга, или Бесплатная электронная книга по основам, и тогда вы сможете лучше решить, в каком направлении вам следует двигаться.
Другие советы
MVC ни в коем случае не является единственным шаблоном проектирования для Интернета, но он полезен.
По моему мнению, принятие только буквы «М» принесет дивиденды, даже если вы не можете / не хотите использовать «V» или «C».
Многие люди, в том числе и я, считают подход, который вы обсуждаете, хорошим!Изучение этого подхода потребует некоторых усилий, но пусть это вас не смущает!
А как насчет того, чтобы просто попробовать небольшой проект с LINQ to SQL?Возможно, найти хороший эталонный проект на Google-код, и изучите, как с ним работали другие.
Это простой инструмент, который позволит вам ознакомиться с некоторыми проблемами, возникающими при сопоставлении объектов с базами данных.
Тогда вы сможете почувствуй это, и решите, стоит ли оно того, чтобы учиться.
Появятся новые концепции, которые нужно понять и экспериментируйте с такими вещами, как:
- Единица работы:Когда вы выполняете «Сохранить», «Удалить» и т. д., ORM имеет тенденцию не делать это немедленно, тогда как DAL на основе набора записей сделает это.Это может быть удивительным, поэтому вам нужно немного узнать об этом.Прочтите о Шаблон единицы работы чтобы получить понимание этого.
- Массовые операции являются проблемой с OR/M.Средство чтения данных может эффективно перебирать тысячи строк, но с ORM нужно быть осторожным при работе с большими пакетами объектов.Опять же, есть над чем почитать.
- Ассоциации выглядеть великолепно, когда можешь делать такие вещи, как
customer.Orders.Count
но они также являются причиной многих проблем.Вам нужно будет найти некоторые безопасные методы, которым следует следовать при работе с ассоциациями.
...назвать несколько.
Для начала не беспокойтесь о наследовании и прочем, просто начните с простого и создайте простые сущности, которые отображаются в таблицах.
Попробуйте использовать их так же, как и существующий DAL.Затем начните экспериментировать с ассоциациями.
Тогда, возможно, попробуйте добавить больше поведения в свои сущности.Если вам это начинает нравиться и вы чувствуете, что вам нужно больше функций, подумайте о том, чтобы попробовать более многофункциональный ORM, например Скорость света или NHibernate.
Надеюсь это поможет!
На мой взгляд, вы пытаетесь сделать то, что LINQ уже может сделать за вас.Если вы застряли в более старой среде, в которой не можете ее использовать, я могу предложить вам использовать Subconic (http://subsonicproject.com/) вместо того, чтобы вручную создавать все эти объекты модели вручную.
У меня был проект, в котором я оказался в аналогичном затруднительном положении, и на полпути я перешел на дозвуковой звук с фантастическими результатами.Более быстрая разработка и НАМНОГО более простой для чтения/использования код.