Постоянство рамки?

Question

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

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

   SessionManager session = new SessionManager (); Order order = session.CreateEntity (); order.Date = DateTime.Now; // Установить другие свойства OrderDetail detail = order.AddOrderDetail (); деталь. Продукт = продукт; // Другие свойства

   // Выполнить все изменения сейчас session.Commit ();

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

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

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

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

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

EDIT:

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

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

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

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

Теперь мы хотим поддержать:

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

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

Answer 1

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

В вашем вопросе вы не указали причину, по которой вам следует переписать функциональность, доступную во многих других местах. Я бы посоветовал, чтобы переосмысление 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 не является его смыслом, и я думаю, что разумно предположить, что часть ORS SubSonic будет уделять меньше внимания, чем специализированные платформы ORM.

Answer 2

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

Answer 3

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

Answer 4

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();
}

Answer 5

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