Структура персистентности?

StackOverflow https://stackoverflow.com/questions/200847

Вопрос

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

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

    Сеанс SessionManager = новый SessionManager();Порядок заказа = session.CreateEntity();заказ.Дата = ДатаВремя.Сейчас;// Установить другие свойства OrderDetail Detail = order.addorderDetail ();деталь.Продукт = продукт;// Другие свойства

    // совершать все изменения сейчас session.commit ();

  2. Должен быть максимально простым и не «слишком гибким».Нам нужен единый способ сделать большинство вещей.

  3. Должна иметь хорошую поддержку объектно-ориентированного программирования.Должен обрабатывать отношения «один-ко-многим» и «многие-ко-многим», должен обрабатывать наследование, поддерживать отложенную загрузку.
  4. Конфигурация предпочтительно основывается на XML.

С моими текущими знаниями я вижу следующие варианты:

  1. Улучшить нашу текущую структуру. Проблема в том, что это требует больших усилий.
  2. ADO.NET Entity Framework — не совсем разбираюсь, но кажется слишком сложным и имеет плохие отзывы.
  3. LINQ to SQL — не имеет хорошей обработки объектно-ориентированных методов.
  4. nHibernate — кажется хорошим вариантом, но некоторые пользователи сообщают о слишком большом количестве устаревших ошибок.
  5. SubSonic — Судя по краткому вступлению, он кажется слишком гибким.Мне этого не надо.

Что вы предложите?

РЕДАКТИРОВАТЬ:

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

  1. Он основан на наборах данных, поэтому первое, что вы делаете, - это настройка наборов данных и записи запросов, которые вам нужны.
  2. Вы создаете файл конфигурации XML, который определяет, как таблицы DataSet сопоставляются с объектами, а также указываете связи между ними (поддержка всех типов ассоциаций).3. Специальный инструмент анализирует конфигурацию XML и генерирует необходимый код.4.Сгенерированные классы наследуются от общего базового класса.

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

  1. Каждая таблица должна иметь один столбец в качестве первичного ключа.
  2. Все таблицы должны иметь первичный ключ одного и того же типа данных, сгенерированного на клиенте.
  3. Для обработки наследования поддерживается только наследование одной таблицы.Кроме того, файл XML почти всегда предлагает единственный способ добиться чего-либо.

Сейчас мы хотим поддержать:

  • Удалите зависимость из DataSets.Код SQL должен генерироваться автоматически, но платформа НЕ должна генерировать схему.Я хочу вручную управлять схемой БД.
  • Более надежная поддержка иерархий наследования.
  • Дополнительная интеграция с LINQ.

Надеюсь, теперь стало яснее, что я ищу.

Это было полезно?

Решение

Улучшить нашу текущую структуру. Проблема в том, что это требует больших усилий.

В своем вопросе вы не указали причину, по которой вам следует переписать функциональность, доступную во многих других местах.Я бы предположил, что переизобретение ORM не будет хорошей тратой вашего времени, если только у вас нет уникальных потребностей в ORM, которые вы не указали в своем вопросе.

Платформа сущностей ADO.NET

Мы используем Entity Framework в реальном мире, в производственном программном обеспечении.Сложный?Насколько я могу судить, не больше, чем у большинства других ORM. то есть «довольно сложно». Однако он относительно новый, и поэтому у него меньше опыта и документации, чем у чего-то вроде NHibernate.Так что отсутствие документации вполне может усложнить задачу.

Entity Framework и NHibernate используют совершенно разные подходы к проблеме преодоления объектно-реляционного разрыва.Я написал об этом немного подробнее в этот пост в блоге.Вам следует подумать, какой подход имеет для вас наибольший смысл.

О Entity Framework было много комментариев, как положительных, так и отрицательных.Некоторые из них вполне обоснованы, а некоторые, похоже, исходят от людей, которые продвигают другие решения.К обоснованной критике относятся

  • Отсутствие поддержки POCO.Это не проблема для некоторых приложений, это проблема для других.Поддержка POCO, скорее всего, будет добавлена ​​в будущих выпусках, но сегодня лучшее, что может предложить Entity Framework, — это IPOCO.
  • Монолитный файл сопоставления.Для нас это не было большой проблемой, поскольку наши метаданные не меняются постоянно.

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

LINQ to SQL — не имеет хорошей обработки объектно-ориентированных методов.

Я согласен.Мне также не нравится акцент на SQL Server.

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

Что ж, в NHibernate хорошо то, что вокруг него очень активное сообщество, и когда вы сталкиваетесь с этими эзотерическими ошибками (и поверьте мне, в Entity Framework тоже есть своя доля эзотерических ошибок;кажется, это связано с территорией) часто можно очень легко найти решения.Тем не менее, у меня не так уж много личного опыта работы с NHibernate, за исключением проведенной нами оценки, которая привела нас к выбору Entity Framework, поэтому я позволю другим людям с более непосредственным опытом прокомментировать это.

SubSonic — Судя по краткому вступлению, он кажется слишком гибким.Мне этого не надо.

SubSonic, конечно, — это гораздо больше, чем просто ORM, и пользователи SubSonic имеют возможность выбрать другую реализацию ORM вместо использования ActiveRecord SubSonic.Я бы рассмотрел его в качестве платформы веб-приложений.Однако функция ORM не является смыслом его существования, и я думаю, что разумно подозревать, что ORM-части SubSonic будет уделяться меньше внимания, чем специализированным платформам ORM.

Другие советы

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

иБАТИС мой любимый, потому что вы получаете лучший контроль над SQL

Объекты разработчика Express Persistence или XPO как это наиболее известно.Пользуюсь уже 3 года.Он предоставляет все, что вам нужно, кроме того, что он коммерческий и вы связываете себя с другой (одной компанией) для своего развития.Помимо этого, Developer Express — один из лучших поставщиков компонентов и инфраструктур для платформы .NET.

Пример кода XPO:

using (UnitOfWork uow = new UnitOfWork())
{
  Order order = new Order(uow);
  order.Date = DateTime.Now();
  uow.CommitChanges();
}

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top