MVC - существуют ли ситуации, когда они либо неактуальны, либо неуместны?

Question

При разработке приложения с графическим интерфейсом и доступом к базе данных существуют ситуации, когда архитектура MVC не имеет значения?

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

Кроме того, я вижу, что разделение модели и контроллеров необходимо только в том случае, если модель должна быть обновлена ​​/ заменена.

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

Answer 1

Мне нравится MVC, потому что это облегчает думать о том, как разные части приложения будут работать вместе. Если все просто сосредоточено вместе, мне гораздо сложнее визуализировать в голове.

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

Если вам не нравится использовать MVC, вам, вероятно, не следует использовать MVC.

Answer 2

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

MVC не является образцом для небольших применений. Вместо этого вы должны применять его, когда ваш код ООП свободной формы начинает становиться неуправляемым. Ваша кодовая база может реализовывать все SOLID principles, но в какой-то момент вы начнете там заблудиться.

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

_{P.S. Вы также ошибаетесь в том, что такое разделение в MVC. Основное разделение между слоями модели и уровнями представления. Это две основные части приложений MVC. И только после этого с презентационным уровнем происходит разделение между представлениями и контроллерами. Вы можете воспользоваться чтением this article.}

Answer 3

Для меня все сводится к проверке. Автоматическое тестирование кода пользовательского интерфейса является чрезмерно дорогостоящим по сравнению с тестированием кода модели. Гораздо проще достичь охвата тестирования в моделях и контроллерах событий по сравнению с уровнями просмотра.

Если у вас нет необходимости тестировать ваше приложение, и он достаточно мал, чтобы вы могли держать его прямо в своей голове, тогда MVC, вероятно, пустая трата времени. Очень немногие приложения действительно достаточно малы, что эти проблемы не под вопросом. Но если приложение действительно так мало, MVC добавит гораздо больше накладных расходов, чем это будет стоить.

Answer 4

Не думаю, MVC дизайн шаблона, как вы бизнес-архитектуры. Обработайте MVC в качестве архитектуры представления. Существует много аргументов в пользу использования MVC с точки зрения бизнес-архитектуры. Это пример stackoverflow question.

На самом деле, вы ищете N-Tier архитектуры.Там, где она отделена, как DAL, BLL и PL:

Доступ к данным Layer (ДАЛ):

Слой отвечает за inteact с хранения (вставка/обновление/удаление)

BLL:

Слой, в котором находится бизнес-логика. Этот слой является основой вашего приложения. Некоторые люди часто используют термин Middleware (пожалуйста, поправьте меня, если не так), чтобы представить BLL. BLL не знает интерфейс, означает, что он может быть использован приложением Desktop, веб-приложением, мобильным приложение и т.д.

PL:

Это ваша презентация слой или слой UI. MVC, по крайней мере, View и Controller.

Answer 5

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

Преимущества MVC:

• Более ремонтопригодны, потому что это разобщенным (разделение проблем).
• Это более проверяемо, поскольку вы можете тестировать контроллеры.
• Обычно у вас больше контроля над HTML, который генерируется (Да, вы можете сделать то же самое с веб-формами, но только если вы дадите все преимущества веб-форм).
• Ваши веб-страницы будут меньше и быстрее, потому что вы не будете , перемещая страницу/представление/состояние управления.
• Интегрируется лучше с клиентской стороны образа жизни и библиотек (Bootstrap, Jquery и это много плагинов, AJAX и т.д.)

Преимущества WebForms:

• Более 3-й элементы управления партии (WebForms опирается в основном на сторонние элементы управления или пользовательские элементы управления для быстрой разработки приложений).
• Если вам нужно viewstate, то требуется меньше работы, но это довольно редкий, если он настроен правильно.
• Интеграция лучше с библиотеками управления на стороне сервера.

Конечно, кто-то скажет, почему вы указали xyz как преимущество для чего угодно, потому что вы можете сделать это и в другом! Ну, вы можете достичь того же самого в обеих рамках, это просто вопрос легкости. То, что легко для одного, может быть сложнее в другом, но оба они, учитывая достаточное количество времени и ресурсов, тоже могут это сделать.

Answer 6

MVC около разделение проблем и решение этих проблем проверяемый.

Кто-то сказал, что «MVC не является образцом для небольших приложений». Я не согласен. Зачем? Это только диктует, как вы разделяете проблемы, я не понимаю, почему это должно быть разным для небольших приложений. Я бы сказал, что это еще проще, потому что каждый разработчик использует тот же шаблон и привык к нему. Это не накладные расходы, это согласованность. Также посмотрите, что должен сказать this guy.

Другое дело: MVC представляет собой шаблон слоя представления (отдельная презентация), это означает, что он логически разделяет ваш пользовательский интерфейс в моделях, представлениях и контроллерах. Контроллеры отвечают за управление потоком, взаимодействие с бэкэнд-системой для запроса и сохранения данных и преобразование этих данных в модели (или модели просмотра), которые используются представлениями.

Бэкэнд сам по себе представляет собой еще одну систему, которая имеет свою собственную независимую архитектуру с услугами, областью и уровнем данных (например, луковая архитектура, пример которой можно найти here).