Поскольку Дж. Тихон отлично справился с объяснением функций EF, я просто перечислил области, в которых NHibernate запускает круги вокруг EF:

• Кэширование
  • EF не имеет ничего из коробки; есть только неподдерживаемый образец
  • NH имеет полную поддержку кэширования, включая аннулирование базы данных на основе БД. Он также расширяется и основан на провайдерах, то есть он работает с различными типами локальных и распределенных кэшей
• дозирующий
  • EF не имеет
  • NH имеет обширную поддержку групп ленивых нагрузок сущностей или коллекций сразу (в любом БД) и сохраняющихся изменений одинаково (Oracle и SQL Server). Также есть многопользовательские и будущие запросы, позволяющие произвольно группировать разные запросы, отправляемые в одном обратном направлении.
• Типы пользователей
  • EF не имеет расширяемости вообще. Он даже не поддерживает свойства Enum
  • Никакие сопоставления типов не жестко закодированы в NH. Вы можете расширить его, чтобы поддерживать любые типы значений, которые вы можете создать, изменить способ отображения существующих типов и т. Д.
• Поддержка коллекции
  • EF поддерживает только простые коллекции объектов. Многие-ко-многим всегда используют составной ключ
  • NH поддерживает коллекции объектов, типы значений, типы компонентов, а также индексированные коллекции и словари (где и ключ, и значение могут быть любого типа). Поддерживаются коллекции «многие ко многим» с собственным ключом (idbag)
• логирование
  • EF не имеет выхода из строя. Существует такой же неподдерживаемый образец, указанный выше
  • NH имеет обширную регистрацию, что позволяет легко отлаживать проблемы. По умолчанию используется log4net, но вы можете использовать любую инфраструктуру ведения журнала, которую хотите
• Запрос
  • EF имеет LINQ в качестве основного языка запросов. LINQ имеет высокий импеданс при сопоставлении с реляционными базами данных. Поставщик EF не поддерживает использование объектов в качестве параметров; вы всегда должны использовать идентификаторы. Существует также язык запросов, который плохо документирован
  • NH имеет LINQ (не такой полный, как EF, хотя), HQL, QueryOver и Criteria.
• Система событий и перехватчики
  • EF почти ничего не имеет
  • NH имеет мощную систему событий, которая позволяет продлить или заменить ее поведение в любой момент сеанса lifecyle: загрузка объектов, постоянные изменения, сброс и т. Д.

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

EF следует обычной модели MS, делающей вещи закрытыми по умолчанию, и мы увидим, что расширилось позже.

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

Например, начать работу с Entity Framework довольно легко, так как вы можете просто запустить Designer в Visual Studio и работать с ORM за считанные минуты. Но в итоге вы получаете Entity-Classes, привязанные к ObjectContext, созданным дизайнером (этого можно избежать с помощью настраиваемого шаблона T4). Это не обязательно плохо, но это подход Microsoft «Начало работы», который вы не хотите использовать в реальном приложении.

Но если вы погружаетесь глубже в Entity Framework, вы можете увидеть, как вы можете избежать большинства ошибок: Дизайнер создает файл EDMX, который (если вы посмотрите на него в редакторе XML) – это не что иное, как комбинация из трех основные аспекты ORM, физическое хранилище (ваша firebase database), концептуальная модель (classы объектов) и сопоставление между ними. Пользовательское действие сборки, применяемое к файлам .edmx в Visual Studio, разделит эти 3 части на три отдельных файла и добавит их в сборку в виде встроенных ресурсов. При создании ObjectContext путь к этим трем файлам используется в ConnectionString (который всегда выглядит немного запутанным для меня). То, что вы на самом деле можете сделать здесь, – все это делается самостоятельно. Это означает запись схемы хранения, концептуальной модели и отображения в XML-редакторе (так же, как и NHibernate), и встраивания их в сборку, содержащую вашу модель.

Базовый базовый class Entity Framework «ObjectContext» может быть построен из этих трех файлов (требуется MetadataWorkspace и EntityConnection), но дело в том, что вы полностью контролируете создание объекта ObjectContext. Это открывает двери для многих функций, которых вы не ожидаете от Entity Framework. Например: вы можете встроить несколько схем хранения SSDL в одну сборку для соответствия определенному типу базы данных (обычно я добавляю один для SQL Server и один для SQL Server CE 4.0). И создайте перегрузку конструктора, которая выбирает подходящую схему хранения для определенного типа DbConnection.

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

interface ICatalog { IEntitySet
 { get; } void Save(); } interface IEntitySet : IQueryable { void Add(T); void Remove(T); } class EntityFrameworkCatalog : ICatalog { ... } 

Но создание репозитория, если у вас есть объектный объект ObjectContext, очень просто, плюс вы получаете IQueryable. Исходя из этой информации, вы можете избежать сильной связи между вашими службами и ORM и полностью измотать структуру Entity Framework в тестах. Кроме того, при тестировании реализации Entity Framework вы можете использовать базу данных SQL Server CE во время модульных тестов, чтобы убедиться, что ваши сопоставления прекрасны (как правило, разные схемы хранения для CE и полномасштабного SQL Server – это всего лишь несколько данных, типов). Таким образом, вы можете проверить все варианты исполнения Entity Framework просто отлично.

Это делает платформу Entity Framework красивой с современными концепциями программного обеспечения, но она не применяет к вам такую ​​практику, что упрощает «Начало работы».

Теперь к сложным битам: Entity Framework имеет небольшой набор поддерживаемых типов CLR, которые в основном include только примитивные, такие как ints, строки и байтовые массивы. Он также обеспечивает некоторый уровень сложных типов, которые следуют тем же правилам. Но что, если у вас есть сложное свойство объекта, такое как представление документа DOM, которое вы хотели бы преобразовать в XML в базу данных. Насколько я знаю, NHibernate предоставляет функцию IUserType, которая позволяет вам определить такое сопоставление для вас. В Entity Framework это становится намного сложнее, но по-прежнему остается по-своему. Концептуальная модель позволяет включать в себя комплексные комплексные типы сборки (пока вы укажете ObjectContext об этом (ObjectContext.CreateProxyTypes (Type [])). Таким образом, вы можете создать оболочку для вашего исходного типа, которая известна только для платформа Entity Framework:

  class Document : IXmlSerializable { } class Article { public virtual Document Content { get; set; } } internal class EntityFrameworkDocument : Document { public string Xml { get { // Use XmlSerializer to generate the XML-string for this instance. } set { // Use XmlSerializer to read the XML-string for this instance. } } } 

Хотя EF теперь может возвращать эти сериализованные документы из хранилища, записывая их на него, требует перехвата хранения статьи и замены простого документа на EntityFrameworkDocument, чтобы гарантировать, что EF может его сериализовать. Я уверен, что другие ORM делают это довольно легко, и это становится хуже. В настоящее время нет способа сделать то же самое с classом System.Uri (который является неизменным, но в противном случае работает) или Enum. Помимо этих ограничений вы можете вместить EF в большинство ваших потребностей. Но вы потратите много времени на это (как и я).

Поскольку мой опыт работы с другими ОРМ ограничен, я бы подвел итог:

• Entity Framework находится в GAC, даже в профиле клиента
• Entity Framework может быть настроен для представления даже сложных типов сущностей (включая некоторые саморегуляции «многие ко многим» или, например, сериализацию XML)
• Его можно «отвлечь», так что вы можете придерживаться IRepository и т. Д.
• Реализация IQueryable (хотя это не так полно, как DataObjects.Net)

• Для этого требуется только System.Data и System.Data.Entity, вы можете даже включить несколько схем хранения для других поставщиков, которые обычно требуют ссылки, но если вы придерживаетесь DbConnection, вы можете просто сделать это:

  ICatalog Create(DbConnection connection, string storageSchemaPath) ICatalog CreateMySql(DbConnection mySqlConnection) { return Create(connection, "res://Assembly/Path.To.Embedded.MySql.Storage.ssdl"); }

Редактирование Недавно я узнал, что если ваши сущности и ваша реализация «каталога» находятся в одной сборке, вы можете использовать внутренние свойства для процесса сериализации XML. Поэтому вместо получения внутреннего Document EntityFrameworkDocument из Document вы можете добавить внутреннее свойство Xml к самому classу Document . Это по-прежнему применяется только в том случае, если у вас есть полный контроль над вашими сущностями, но он устраняет необходимость перехвата любых изменений в каталоге, чтобы убедиться, что ваш производный class используется. CSDL выглядит одинаково, EF просто позволяет отображаемому свойству быть внутренним. Я все же должен убедиться, что это будет работать в средах среднего доверия.

Надеюсь, что все это поможет

• NHibernate vs Entity Framework

• Открыть ORM vs Entity Framework

• Чрезвычайно хорошее сравнение

Когда мы используем ADO.NET с нуля рано или поздно, мы расстраиваемся и начинаем искать другие решения. Я тестировал многие из них. Большинство из этих структур ORM имеют множество функций и требуют большого количества знаний. Некоторым кажется очень легким в начале (например: EF, Castle ActiveRecord), но есть много вещей, о которых вы должны заботиться:

• Кэширование
• Отношение «многие ко многим»
• Ленивая загрузка
• наследование
• Композитные клавиши
• Как инкапсулировать инфраструктуру от абонентов
• Как генерируются инструкции SQL
• Представление
• Как сделать расширенные запросы к базе данных

Если вы опытный разработчик, и вы готовы ко всем этим ловушкам и материалам, я спрашиваю вас: являются ли ваши товарищи по работе?

Есть более простые способы кодирования ADO.NET и не потерять контроль над тем, что происходит. Взгляните на PainlessDAL .

«Элегантное» кодирование не всегда является лучшим способом.