Подтвердить что ты не робот

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

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

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

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

 static UserIO.SaveUser(User user)

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

User.Save()

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

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

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

4b9b3361

Ответ 1

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

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

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

Ответ 2

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

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

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

В целом, общий принцип хорошего проектирования системы - это принцип

Ответ 3

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

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

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

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

Ответ 4

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

Ответ 5

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

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