My<cod/>.net
Лучше ли создавать классы моделей или придерживаться общего класса утилиты базы данных?
У нас есть простой служебный класс в доме для наших вызовов базы данных (легкая оболочка вокруг ADO.NET), но я думаю о создании классов для каждого database/object. было бы разумно сделать это, или это только выиграло бы, если бы мы использовали полную структуру 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();
Будет ли это умно, или это будет перебор? Я вижу выгоду для повторного использования, изменения базы данных и maintenance/readability.
Этот вопрос загружен, дизайн, управляемый данными, против дизайна, управляемого доменом. Для любого приложения, которое имеет хорошее поведение, то доменное проектирование должно быть предпочтительным. Отчеты или служебные приложения, как правило, работают лучше (или быстрее разрабатываются) с дизайном, управляемым данными.
Вы спрашиваете: "должна ли моя компания сделать фундаментальный сдвиг в том, как мы разрабатываем наш код". Как домен-урод, моя внутренняя реакция-кричать " Да". Однако, по простому характеру вашего вопроса, я не уверен, что вы полностью понимаете масштабы изменения, которое вы предлагаете. Я думаю, тебе следует больше говорить об этом со своей командой.
Возьмите какую-нибудь литературу, например книгу Эвана DDD или электронную книгу free Foundation, и тогда вы будете в лучшем положении , чтобы судить, в каком направлении вам следует идти.
Подход, который вы обсуждаете, считается хорошим многими людьми, включая меня! Изучение этого подхода потребует некоторых усилий, но не позволяйте этому оттолкнуть вас!
Как насчет того, чтобы просто попробовать небольшой проект с LINQ до SQL ? Возможно, найти хороший справочный проект на Google code и изучить, как другие работали с ним.
Это простой инструмент, который позволит вам ознакомиться с некоторыми проблемами, возникающими при сопоставлении объектов с базами данных.
Затем вы сможете почувствовать это и решить, стоит ли это кривой обучения.
Там будут новые концепции, чтобы понять и экспериментировать с такими вещами, как:
- Единица работы: когда вы выполняете сохранение и удаление и т. д., ORM, как правило, не делает этого сразу, тогда как набор записей на основе DAL будет. Это может быть удивительно, так что вам нужно будет узнать немного об этом. Прочитайте на единицу работы шаблон , чтобы получить представление об этом.
- Массовые операции -это проблема с OR/M. читатель данных может эффективно перебирать тысячи строк, но с ORM вы должны быть осторожны при работе с большими партиями объектов. Опять же, один, чтобы читать дальше.
- Ассоциации кажутся отличными, когда могут делать такие вещи, как
customer.Orders.Count, но они также являются причиной многих проблем. Вам нужно будет найти некоторые безопасные методы работы с ассоциациями.
..... чтобы назвать несколько.
Для начала, не беспокойтесь о наследовании и прочем, просто начните с простого и имейте простые сущности, которые сопоставляются с таблицами.
Попробуйте использовать их так же, как вы используете существующий DAL. Затем начните экспериментировать с ассоциациями.
Тогда, возможно, попробуйте добавить больше поведения в свои сущности. Если вам это начинает нравиться, и вы чувствуете, что вам нужно больше возможностей, подумайте о том, чтобы попробовать более многофункциональный ORM, такой как Lightspeed или NHibernate .
Надеюсь, это поможет!
Мне кажется, что вы пытаетесь сделать то, что LINQ уже может сделать для вас. Если вы застряли в старой структуре, в которой вы не можете использовать это, я мог бы предложить вам использовать Subconic ( http://subsonicproject.com/ ) вместо того, чтобы вручную создавать все эти объекты модели вручную.
У меня был проект, где я был в аналогичном затруднительном положении и изменился на subsonic на полпути с фантастическими результатами. Более быстрая разработка и MUCH легче читать / использовать код.