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

Question

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

Наша система изначально была построена с использованием .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 уже не за горами, я должен просто продолжить свой подход к файлу "IO" и начать с Entity Framework, когда C # 4.0 будет наконец выпущен. Или, может быть, есть более элегантная структура класса, которую я мог бы использовать, например? использование частичных классов?

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

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

Answer 1

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

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

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

Answer 2

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

• NHibernate
• LLBLGen
• Ibatis

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

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