Почему не рекомендуется передавать объекты как модели в MVC?

Ответ 1

Основной проблемой здесь является связь. Идея модели, которая является "М" в "MVC", заключается в том, что она не имеет внешних зависимостей. Это "ядро" вашего приложения. Дерево зависимостей хорошо продуманной архитектуры приложения должно выглядеть примерно так:

                       +---------------------------------------> Views
                       |                                           |
                       |                                           |
                       |                                           v
                  Controllers ----+-> Model Transformer -----> View Model
                       |           \         |
                       |            \        |
                       v             \       v
Data Access <---- Persistence --------> Domain Model
                       |             /
                       |            /
                       v           /
                     Mapper ------+

Теперь я понимаю, что не совсем убедительно просто сказать "здесь архитектура, это то, что вы должны использовать", поэтому позвольте мне объяснить, что происходит здесь:

• Контроллер получает запрос.
• Контроллер вызывает какой-то уровень сохранения (т.е. репозиторий).
• Уровень Persistence извлекает данные, затем использует mapper для сопоставления с моделью домена.
• Контроллер использует трансформатор для изменения модели домена в модель представления.
• Контроллер выбирает необходимый вид и применяет к нему модель просмотра.

Итак, почему это хорошо?

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

• Уровень persistence возвращает экземпляры модели домена. Это означает, что он может быть смоделирован как полностью абстрактный, платформенно-агностический интерфейс. Компонент, который должен использовать уровень сохранения (например, контроллер), не принимает никаких дополнительных зависимостей. Это идеально подходит для инъекций зависимостей уровня персистентности и, опять же, тестируемости. Комбинация сохранения, доступа к данным и картографа может жить в собственной сборке. В более крупных проектах вы даже сможете еще разделить устройство сопоставления и заставить его работать с общим набором записей.

• Контроллер имеет только две нисходящие зависимости - модель домена и уровень сохранения. Модель должна редко меняться, так как это ваша бизнес-модель, и поскольку уровень персистентности является абстрактным, контроллер почти не нужно менять (кроме добавления новых действий).

• Представления зависят от отдельной модели пользовательского интерфейса. Это изолирует их от изменений в модели домена. Это означает, что если ваша бизнес-логика меняется, вам не нужно менять каждый вид в вашем проекте. Это позволяет представлениям быть "глупыми", поскольку представления должны быть - они не намного больше, чем заполнители для просмотра данных. Это также означает, что было бы просто воссоздать представление, используя другой тип пользовательского интерфейса, то есть смарт-клиентское приложение, или переключиться на другой механизм просмотра (Spark, NHaml и т.д.).

Теперь при использовании O/R Mappers, таких как Linq to SQL или Entity Framework, очень заманчиво рассматривать классы, которые они генерируют в качестве модели вашего домена. Это, безусловно, выглядит как модель домена, но это не так. Почему?

• Классы сущностей привязаны к вашей реляционной модели, которая со временем может и будет значительно отличаться от вашей модели домена;

• Сущности классов тупые. Трудно поддерживать любые сложные сценарии валидации или интегрировать любые бизнес-правила. Это называется моделью анемической области.

• У классов сущностей есть скрытые зависимости. Хотя они могут казаться обычными POCOs, они могут фактически иметь скрытые ссылки на базу данных (т.е. Ленивую загрузку ассоциаций). Это может привести к тому, что проблемы, связанные с базой данных, будут пузыряться до логики представления, где вы в наименьшей степени сможете правильно проанализировать, что происходит и отлаживать.

• Но самое главное, "модель домена" уже не является независимой. Она не может жить вне любой сборки, имеющей логику доступа к данным. Ну, это может быть, есть способы обойти это, если вы действительно работаете над этим, но это не так, как это делают большинство людей, и даже если вы это сделаете, вы обнаружите, что фактический дизайн домена модель ограничена вашей реляционной моделью и, в частности, тем, как ведет себя EF. Суть в том, что если вы решите изменить свою модель персистентности, вы нарушите модель домена, а ваша модель домена станет основой для всего остального в вашем приложении.

Классы Entity Framework немодель домена. Они являются частью реляционной модели данных и имеют одинаковые или похожие имена, которые вы могли бы дать классам в модели домена. Но они отличаются друг от друга с точки зрения управления зависимостями. Использование классов, созданных с помощью инструмента ORM в качестве модели вашего домена, может привести только к чрезвычайно хрупкой архитектуре/дизайну; каждое изменение, которое вы делаете практически в любой части приложения, будет иметь множество предсказуемых и непредсказуемых каскадных эффектов.

Есть много людей, которые, похоже, думают, что вам не нужна сплоченная независимая модель домена. Обычно оправдание состоит в том, что (a) это небольшой проект, и/или (b) их модель домена действительно не имеет никакого поведения. Но небольшие проекты становятся большими, а бизнес-правила становятся (намного) более сложными, а анемичная или несуществующая модель домена - это не то, что вы можете просто реорганизовать.

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

Ответ 2

Одна потенциальная проблема с этим дизайном заключается в том, что представление может повторяться через объекты модели (которые ленивы загружаются) более одного раза и вызывать ненужные накладные расходы. Например, если веб-страница отображает одни и те же данные в двух разных формах в нескольких разных местах на странице, она дважды проверит запрос и вызовет две обратные поездки в базу данных (посмотрите на теги под вопросом и на боковой панели на этой странице, и предположим, что они пришли из одного запроса). Представление может справиться с этой проблемой, кэшируя результаты один раз и повторяя два раза в кэшированных данных, но это не то, что должно рассматриваться. Он должен представить данные, данные ему, не беспокоясь об этом.

Ответ 3

Проблема в том, что ваш пользовательский интерфейс больше привязан к вашей организации, чем необходимо.

Если ваш объект инкапсулирован с помощью ViewModel, ваш пользовательский интерфейс может содержать не только объект (данные, которые он хочет в конечном итоге сохранить), но также может добавлять больше полей и больше данных, которые могут использоваться контроллером для создания решений и использоваться View для управления дисплеем. Для передачи одних и тех же данных за пределами ViewModel потребуется, чтобы вы использовали параметры метода действий и конструкторы ViewData, которые не масштабируются, особенно для сложных ViewModels.

Ответ 4

Взгляд глупо и невежественен. Он не должен и не хочет ничего знать. Его очень мелкие и фокусы только на дисплее. Это хорошо, поскольку представление делает то, что он делает лучше всего.

Поступая таким образом, вы сталкиваетесь с проблемой, связанной с данными, с представлением, и, кроме того, вы ограничиваете просмотр только данными из своей сущности как сильно типизированной модели.

Кроме того, вы разрешаете вам зависимость от EF, полностью переходите к представлению и проникаете в приложение, где вы должны стараться быть так же слабо связанными с этой зависимостью, как вы можете.