Стойкость?

Question

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

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

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

   // Зафиксировать все изменения сейчас 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 в реальном мире, производства программного обеспечения. Сложно? Не более, чем большинство других ОРМ, насколько я могу судить, , то есть «довольно сложно». Однако он относительно новый, и, как таковой, существует меньше опыта сообщества и документации, чем что-то вроде NHibernate. Таким образом, отсутствие документации может показаться более сложным.

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

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

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

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

LINQ к SQL - не имеет хорошую управляемость объектно-ориентированных методов

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

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

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

SubSonic - из краткого введения кажется слишком гибким. Мне этого не надо.

SubSonic, конечно, намного больше, чем просто ORM, и пользователи SubSonic имеют возможность выбора другой реализации ORM вместо использования ActiveRecord SubSonic. Будучи платформой веб-приложений, я бы это рассмотрел. Тем не менее, его функция ORM не является его raison d'être, и я думаю, что разумно подозревать, что часть ORM SubSonic получит меньше внимания, чем выделенные рамки ORM.

Answer 2

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

Answer 3

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

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

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