Вотум недоверия Платформы объекта - релевантный в.NET 4?

Мне всегда казалось, что в основе "вотума недоверия" лежала попытка использовать EF так, как будто это клон NHibernate. Это не так, и даже в EF 4 попытка использовать EF как подделку NHibernate, вероятно, закончится неудачей, хотя вы можете пройти немного дальше, прежде чем потерпите неудачу. В качестве тривиального примера, большинство людей используют LINQ в NHibernate на минимальной основе, если вообще используют, в то время как я не думаю, что вы можете быть продуктивным в EF вообще, если вы не используете LINQ достаточно сильно.

С другой стороны, я довольно успешно использую EF 1 на его собственных условиях и не позволяю заявлениям людей в блогах мешать мне работать с ним. Я с нетерпением жду возможности использования многих новых функций в EF 4, но я буду рад работать над хорошо структурированным проектом EF 1 в любое время. (Если уж на то пошло, я с удовольствием работаю и с NHibernate и не стану критиковать его за то, что он не ведет себя как EF.)

Поэтому я пытаюсь в несколько деликатной форме намекнуть, что прежде чем вы сможете решить, остаются ли "утверждения, сделанные в "Голосе недоверия", в силе (в .NET 4)...", вы должны сначала решить, были ли эти утверждения когда-либо в силе для вас и того, как вы работаете. Если ваше личное понимание O/R жестко привязано к NHibernate, то EF 4, вероятно, все еще будет казаться вам второсортным. Если же, с другой стороны, вы готовы изучить EF-метод работы, то, вероятно, даже EF 1 покажется вам лучше, чем вы слышали.

Обратимся непосредственно к заявлениям о "недоверии" и рассмотрим как их суть, так и то, что изменилось в EF 4:

НЕОБХОДИМОЕ УПРАВЛЕНИЕ ДАННЫМ АСПЕКТОМ СУЩНОСТЕЙ ВЕДЕТ К ДЕГРАДИРОВАННЫМ АРХИТЕКТУРАМ СУЩНОСТЕЙ:

Это непонимание модели данных сущностей в Entity Framework. (Или, если хотите, разница во взглядах) Но в любом случае это особенность, а не ошибка. Entity Framework разработан вокруг более общего случая сервисов данных, а не только O/R моделирования в частности. Наложение поведений на сущности, возвращаемые из службы данных, приводит к катастрофе в стиле CORBA. В отличие от ORM, где вы, в некоторой степени, застряли с любым типом, выходящим из черного ящика ORM, в модели Entity Framework от вас ожидается проекция на бизнес-типы. В этом случае сопоставленные типы сущностей никогда даже не будут материализованы.

Это существенное различие между моделью Entity Framework и многими другими ORM. Лично я нахожу, что разделение бизнес-поведения и отображения O/R гораздо чище, чем их объединение. Вы не обязаны соглашаться с этой идеей, но это явно дизайнерское решение, а не недосмотр.

EXCESS CODE NEEDED TO DEAL WITH LACK OF LAZY LOADING:

EF 4, к лучшему или худшему, имеет ленивую загрузку.

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

Тем не менее, бывают случаи, когда ленивая загрузка удобна. Поэтому я рад, что она добавлена в EF 4.

SHARED, CANONICAL MODEL CONTRADICTS SOFTWARE BEST PRACTICES:

Трудно понять, что из этого следует, поскольку часть сопроводительного текста даже не является связным английским, например:

Подход с канонической моделью, чреватый неудачами, не был сложным из-за отсутствия продуманного инструментария, подобного Entity Framework.

Этот раздел кажется предполагает, что Entity Framework налагает какое-то требование или, по крайней мере, сильное предубеждение к использованию единственной, канонической модели данных для сложной системы. Я не уверен, что согласен с этим, но трудно сказать, учитывая отсутствие какого-либо конкретного примера в этом разделе. Поэтому я расскажу вам о своих собственных предубеждениях по этому вопросу, а вы можете согласиться или не согласиться со мной:

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

Так, одно большое приложение для сложной системы может быть такой же большой ошибкой, как и одна большая модель данных. Поэтому было бы неправильно, если бы Entity Framework упрощал объединение множества маленьких моделей в одно слишком большое приложение; это просто заменило бы одну проблему другой.

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

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

ИГНОРИРОВАНИЕ ОТСУТСТВИЯ ПЕРСИСТЕНЦИИ ПРИВОДИТ К ТРУДНОСТИ ЧТЕНИЯ, ПИСЬМА И МОДИФИКАЦИИ БИЗНЕС-ЛОГИКИ, В результате чего затраты на разработку и обслуживание увеличиваются с огромной скоростью:

В этом разделе содержатся утверждения, которые я считаю ошибочными:

Entity Framework поощряет антипаттерн Anemic Domain Model, препятствуя включению бизнес-логики в классы сущностей.

См. выше. Я думаю, что работа типов сущностей заключается в отображении реляционного пространства в объектное. Согласно принципу единой ответственности, эти типы должны модифицироваться только тогда, когда меняется их единственная задача. Если бизнес-процессы меняются, то это ответственность, не связанная с отображением O/R. Возможно, ограничения других ORM накладывают технический барьер на разделение этих обязанностей. Вполне нормально отступать от правил, когда диктует технология, если цена чистоты дизайна чрезмерна. Но я решительно поддерживаю подход к типам сущностей без поведения.

В своем нынешнем состоянии классы сущностей EF не могут быть эффективно протестированы независимо от базы данных.

Это просто неправильно. Тот, кто это написал, не понимает, о чем говорит. Ни один из наших юнит-тестов не затрагивает БД, никогда, а многие включают EF.

Что касается сути названия этого раздела, то в EF 4 есть изменения. Теперь можно иметь полностью нечувствительные к персистентности типы сущностей, если это поможет вашему проекту. Однако, начиная с самой ранней версии Entity Framework, вы могли проектировать на POCO. Таким образом, игнорирование персистентности всегда было доступно, когда это требовалось. Наличие persistence ignorance на самих типах сущностей позволяет отслеживать изменения с объектом, игнорирующим персистентность. Это может быть полезно в некоторых случаях. Но это значительно меньшее подмножество случаев, чем фальшивые утверждения о модульном тестировании, что значительно снижает влияние того момента, о котором говорится в документе.

ЭКСКЛЮЗИВНЫЕ КОНФЛИКТЫ СЛИЯНИЯ С ИСТОЧНИКОМ КОНТРОЛЯ В КОМАНДЕ:

Действительно ли слияние XML настолько сложно? Если да, то, возможно, стоит поискать новый инструмент для слияния. Я не нахожу это проблематичным.

Однако здесь есть реальная проблема, хотя, опять же, она гораздо более узкая, чем утверждается в документе. Чтобы не повторяться, я просто направлю вас к моему сообщению на эту тему.

В EF 4 можно использовать модели, основанные на коде, а не на XML, чтобы разделить модель на множество различных файлов.