Опции персистентности Объекта.NET
У меня есть вопрос, что я просто не чувствую, что нашел удовлетворительный ответ для, или это, или я не смотрел в правильном месте.
Наша система была первоначально создана с помощью.NET 1.1 (однако проекты, которые все теперь поддерживают 3.5), и все объекты сохраняются к базе данных с помощью хранимых процедур и "SQLHelper", который имеет стандартный ExecuteReader, методы типа ExecutreNonQuery.
Таким образом, то, что обычно происходит, у нас будут наши объекты, например, Пользователь и Роль, и у нас будет другой класс под названием UserIO, который сохраняет те объекты к базе данных с методами как:
static UserIO.SaveUser(User user)
Причина отдельного файла IO состоит в том, чтобы сохранить IO отдельным от объекта, однако не это более удовлетворительный для только для вызова?:
User.Save()
Возможно, я неправ, но это просто не чувствует себя хорошо, чтобы рассеять эти файлы "IO" повсеместно. Таким образом, я думаю о рассмотрении других опций для персистентности, и я задался вопросом, где будет лучшее место для запуска. Я использовал наборы данных в прошлом, но имел некоторый смешанный опыт особенно с их производительностью. Я знаю, что LINQ вокруг теперь, но я слышал, что, а не LINQ должен использовать Платформу Объекта ADO.NET, но затем кто-то еще сказал мне, что Платформа Объекта не совершенно правильна, и я должен ожидать C# 4.0. Если это так, и с C# 4.0 просто за углом должен я только продолжиться с моим файлом "IO", приближаются и запускаются с Платформы Объекта, когда C# 4.0 наконец выпущен. Или существует ли, возможно, более изящная структура класса, которую я мог с помощью, например, используя Частичные Классы?
Я должен сказать, я не смотрю на завершенную замену доступа к данным, который уже существует, я более обеспокоен новыми объектами, которые я создаю.
Я сожалею, если этим вопросом является маленький генерал, однако у меня нет многих людей вокруг для возврата этого вида мысли прочь.
5 ответов
Я успешно использовал Entity Framework 3.5. Есть некоторые, кого я бы охарактеризовал как пуристов, которые считали, что Entity Framework нарушает некоторый набор правил и не должен использоваться.
На мой взгляд, единственные правила, которые имеют значение, - ваши собственные. Я рекомендую вам начать экспериментировать с Entity Framework 3.5, раз уж она у вас есть. Кроме того, как только вы сможете, вам (и почти всем остальным) необходимо начать экспериментировать с .NET 4.0. Релиз-кандидат доступен бесплатно, поэтому нет причин не знать хотя бы о том, что доступно.
Возможно, вам настолько нравятся изменения EF в 4.0, что вам захочется их дождаться. Так же вероятно, что вы не почувствуете необходимости ждать и сможете продолжить и извлечь выгоду из EF, как это было в версии 3.5. У меня есть, и я очень рад, что не стал ждать.
Обычно репозиторий создается отдельно от модели. Имя IO уникально для такого шаблона, но действительно. Теперь, в зависимости от того, с кем вы разговариваете (на ум приходят орехи TDD), у вас могут возникнуть проблемы с использованием статического класса.
Если вы ищете модели объектно-реляционного сопоставления, вы можете изучить:
Здесь также есть более длинный список: http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#.NET
Что касается общего вопроса о том, как разработать объектную модель для обеспечения устойчивости выбор дизайна во многом зависит от сложности системы, требуемой расширяемости, необходимости поддержки нескольких хранилищ сохраняемости (SQLServer, Oracle, файловая система и т. д.) и т. д. Описанный вами шаблон выглядит как DataTansferObject (DTO) . Это обычная конструкция для отделения логики сохраняемости от бизнес-логики.
Кроме того, общим принципом хорошего проектирования системы является принцип единой ответственности . При построении системы вы должны решить, имеет ли смысл объединять различные обязанности в один класс. Объединение обязанностей часто может усложнять систему и создавать конфликты проектирования, которые трудно разрешить.
Наличие набора классов, реализующих функции данных, часто называют многоуровневым программированием. (http://en.wikipedia.org/wiki/N-tier). Выделяя классы, которые обращаются к данным, вы создаете систему, которая гораздо более удобна в обслуживании. Если бы вы объединили эти функции с классами, реализующими бизнес-правила в вашем приложении, вы бы потеряли многие преимущества многоуровневого дизайна.
Наличие функций доступа к данным в собственных классах - это хорошо (3 аплодисмента дизайнеру), но то, что они разбросаны повсюду - это плохо. В идеале вы не хотите, чтобы исходные тексты этих функций находились в одном каталоге или файле (в зависимости от размера проекта). Если они все вместе, вы получаете много преимуществ. Если они разбросаны по (случайному?) множеству мест, это лишает модульность кода смысла.
Шаблон, который я использую довольно часто: Каждый объект имеет следующее:
- Объект передачи данных (DTO) - это сохраняет как можно меньше памяти, используемой наборами данных.
- Бизнес-объект - который принимает в качестве конструктора по крайней мере указанный выше DTO - он будет выполнять любую функцию в DTO, которая не является функцией CRUD
- CRUD / Persistant методы в классе репозитория
Последнее может быть выполнено любой из 2 способов. У вас может быть большой класс репозитория, который подходит для приложений / компонентов с небольшим количеством объектов, или вы можете иметь отдельные репозитории для каждого объекта.
Взгляните на блог Руди Лаковараса. Недавно он написал серию статей об эффективном доступе к данным с использованием аналогичной схемы.