Параметры сохраняемости объектов .NET

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

Наша система изначально была построена с использованием .NET 1.1 (однако все проекты теперь поддерживают 3.5), и все сущности сохраняются в базе данных с использованием хранимых процедур и SQLHelper, который имеет стандартные методы типа ExecuteReader, ExecutreNonQuery.

Итак, что обычно происходит, у нас будут наши сущности, например, User и Role, и у нас будет еще один класс под названием UserIO, который сохраняет эти объекты в базе данных с помощью таких методов, как:

 static UserIO.SaveUser(User user)

Причина для отдельного файла ввода-вывода состоит в том, чтобы отделить ввод-вывод от объекта, но разве не более удовлетворительно просто позвонить ?:

User.Save()

Может быть, я ошибаюсь, но мне кажется неправильным, когда эти "IO" файлы разбросаны повсюду. Итак, я подумываю о поиске других вариантов настойчивости, и мне стало интересно, с чего лучше всего начать. Раньше я использовал наборы данных, но у меня был неоднозначный опыт, особенно с их производительностью. Я знаю, что LINQ уже существует, но я слышал, что вместо LINQ мне следует использовать ADO.NET Entity Framework, но потом кто-то другой сказал мне, что Entity Framework не совсем подходит, и мне следует ждать C # 4.0. Если это так и C # 4.0 не за горами, я должен просто продолжить мой подход к файлам «ввода-вывода» и начать с Entity Framework, когда, наконец, выйдет C # 4.0. Или, возможно, есть более элегантная структура классов, которую я мог бы использовать, например используя частичные классы?

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

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


person MrEdmundo    schedule 04.03.2010    source источник


Ответы (5)


Я успешно использовал Entity Framework 3.5. Есть некоторые, кого я бы охарактеризовал как пуристов, которые считали, что Entity Framework нарушает некоторый набор правил и не должен использоваться.

На мой взгляд, единственные правила, которые имеют значение, - ваши собственные. Я рекомендую вам начать экспериментировать с Entity Framework 3.5, раз уж она у вас есть. Кроме того, как только вы сможете, вам (и почти всем остальным) необходимо начать экспериментировать с .NET 4.0. Релиз-кандидат доступен бесплатно, поэтому нет причин не знать хотя бы о том, что доступно.

Возможно, вам так понравятся изменения EF в 4.0, что вам захочется их дождаться. Так же вероятно, что вы не почувствуете необходимости ждать и сможете продолжить и воспользоваться EF, как это было в версии 3.5. У меня есть, и я очень рад, что не стал ждать.

person John Saunders    schedule 04.03.2010
comment
Спасибо, это хороший стимул не игнорировать EF полностью. Давно хотел посмотреть на RC как на все, хотя время находит! Вы бы сказали, что EF подходит для использования вместе с существующим доступом к данным? Мой вопрос к вам очень похож на вопрос @LBushkin. Спасибо, Эд - person MrEdmundo; 04.03.2010
comment
@MrEdmundo: Я успешно использовал EF 3.5 в производственных приложениях. Проблем с этим очень мало, и они, на мой взгляд, совсем небольшие. - person John Saunders; 05.03.2010

Если вам нужны модели объектно-реляционного сопоставления, вы можете изучить:

Здесь также есть более длинный список: http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#.NET

Что касается общего вопроса о том, как разработать объектную модель для сохранения состояния, выбор дизайна во многом зависит от сложности системы, требуемой расширяемости и необходимости поддержки нескольких хранилищ сохраняемости (SQLServer , Oracle, файловая система и т. Д.) И т. Д. Описанный вами шаблон выглядит как DataTansferObject (DTO). Это обычная конструкция для отделения логики сохраняемости от бизнес-логики.

Кроме того, общим принципом хорошего проектирования системы является принцип единой ответственности. При построении системы вы должны решить, имеет ли смысл объединять различные обязанности в один класс. Объединение обязанностей часто может усложнять систему и создавать конфликты проектирования, которые трудно разрешить.

person LBushkin    schedule 04.03.2010
comment
Спасибо за то, что дали имя довольно длинному описанию :). Считаете ли вы, что описанные вами модели сопоставления подходят для использования на поздних этапах жизненного цикла продукта (как в моем случае), или они больше подходят для разработки с нуля? - person MrEdmundo; 04.03.2010
comment
По-разному. Некоторые библиотеки лучше работают с POCO, другие - нет. Библиотеки, которые требуют от потребителя реализации множества интерфейсов или наследования от определенных базовых классов, явно труднее внедрить в проект на поздних этапах игры. NHibernate, например, относительно хорош в работе с POCO, поэтому вы можете использовать его даже на поздних стадиях проекта. Однако имейте в виду - есть что сказать о последовательности реализации. Наличие нескольких различных способов сохранения данных в приложении может не способствовать долгосрочному обслуживанию или адаптации разработчиков. - person LBushkin; 05.03.2010

Паттерн, который я использую довольно часто, следующий: Каждый объект имеет следующее:

  • Объект передачи данных (DTO) - сохраняет память, используемую наборами данных, как можно меньше.
  • Бизнес-объект - он принимает в качестве конструктора как минимум указанный выше DTO - он будет выполнять любую функцию в DTO, которая не является функцией CRUD.
  • CRUD / Persistant методы в классе репозитория

Последнее можно сделать двумя способами. У вас может быть большой класс репозитория, который подходит для приложений / компонентов с небольшим количеством объектов, или у вас могут быть отдельные репозитории для каждого объекта.

Взгляните на Блог Руди Лаковараса. Недавно он написал серию публикаций об эффективном доступе к данным с использованием аналогичной схемы.

person Jason Summers    schedule 04.03.2010

Обычно репозиторий создается отдельно от модели. Имя IO уникально для такого шаблона, но действительно. Теперь, в зависимости от того, с кем вы разговариваете (на ум приходят орехи TDD), вы можете получить фальшивку за использование статического класса.

person ChaosPandion    schedule 04.03.2010

Наличие набора классов, реализующих функции данных, часто называют многоуровневым программированием. (http://en.wikipedia.org/wiki/N-tier). Выделяя классы, которые обращаются к уровню данных, вы создаете систему, которая намного удобнее в обслуживании. Если вы объедините эти функции в классы, реализующие бизнес-правила в вашем приложении, вы потеряете многие преимущества многоуровневого дизайна.

Распространение функций доступа к данным в их собственные классы - это хорошо (3 ура дизайнера), однако распространять их повсюду - плохо. В идеале вы не должны размещать все эти функции в одном каталоге или файле (в зависимости от размера проекта). Если они все вместе, вы получите много преимуществ. Разделение их на (случайное?) Множество мест лишает смысла модульность этого кода.

person Hogan    schedule 04.03.2010