Особенности - NHibernate против написания пользовательских объектно-реляционных карт

Question

Я ищу список всех функций, которые вы бы реализовали в пользовательском реляционном картографическом объекте (ORM), чтобы соответствовать всем функциям NHibernate.

для начала:

1. переносимость базы данных через различные драйверы и диалекты
2. кеширование
3. ленивая загрузка
4. пользовательский SQL
5. интерфейс запроса - LINQ, критерии, QBE (запрос по примеру)
6. базовые и расширенные функции отображения (например, столбцы дискриминатора, примеры )
7. поддержка транзакций и единиц работы
8. Многокритериальный
9. Multi-запрос
10. Дозировка
11. Крючки для дополнения / переопределения функциональности

<Вставьте свой сюда>

См. Еще один список здесь: 25 причин не писать свой собственный объект реляционного картографа от Ayende Rahien

Answer 1

Ayende опубликовал почти полный список важных функций ORM здесь: http://ayende.com/Blog/archive/2006/05/12/25ReasonsNotToWriteYourOwnObjectRelationalMapper.aspx

Важным, который отсутствует в вашем списке, является проверка IsDirty / State Change. Identity Map - еще одна важная карта, которая включает множество других функций, таких как IsDirty.

Answer 2

Multi query,

Дозирование.

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

Последняя часть - это место, где NHibernate превосходит.

Answer 3

Какой-то интерфейс запроса (например, linq или Criteria)

Какая-то функция отображения всего

Поддержка транзакций и Единица работы