Фреймворк постоянства?

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

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

    SessionManager session = новый SessionManager (); Порядок заказа = session.CreateEntity (); order.Date = DateTime.Now; // Устанавливаем другие свойства OrderDetail detail = order.AddOrderDetail (); detail.Product = product; // Другие свойства

    // Зафиксируем все изменения сейчас session.Commit ();

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

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

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

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

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

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

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

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

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

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

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

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

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


persistence linq linq-to-entities ado.net nhibernate
person Albert    schedule 14.10.2008    source источник

Ответы (5)


arrow_upward
2
arrow_downward

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

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

ADO.NET Entity Framework

Мы используем 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-фреймворки.

person Craig Stuntz    schedule 14.10.2008

arrow_upward
1
arrow_downward

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

person Matt    schedule 14.10.2008

arrow_upward
0
arrow_downward

Мне больше всего нравится iBATIS, потому что вы получаете лучший контроль над SQL

person Simon    schedule 14.10.2008

arrow_upward
0
arrow_downward

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

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

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

arrow_upward
0
arrow_downward

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

person s3v1    schedule 14.10.2008