Почему я должен использовать шаблон MVC?

Кажется, что все веб-приложения в настоящее время хотят использовать MVC для всего. Однако мне трудно убедить себя использовать эту схему. Я понимаю, что общая идея состоит в том, чтобы отделить бэкэнд-логику от интерфейса, который представляет программу. Как правило, кажется, что взгляды в какой-то степени зависят от контроллера, который заканчивается в зависимости от модели. Я не вижу, какая польза от добавления контроллера. Я читал много шумихи о том, «это то, как должны быть разработаны приложения», но, возможно, я до сих пор не понимаю, что должно идти туда. Всякий раз, когда я разговариваю с другими о MVC, кажется, что у всех есть другое представление о том, что принадлежит какой категории.

Итак, почему я должен использовать MVC? Что я могу получить, используя MVC только для того, чтобы отделить интерфейс от бэкэнд-логики? (Большинство «преимуществ», которые я вижу в этом шаблоне, получают только путем отделения интерфейса от реализации и не объясняют цели наличия отдельного «контроллера»)

71 голос | спросил Billy ONeal 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 01 Sep 2011 22:53:47 +0400 2011, 22:53:47

7 ответов


47

Хех. Мартин Фаулер согласен с вашей путаницей в отношении MVC:

  

Мне не кажется ужасно полезным думать о MVC как шаблоне, потому что   он содержит немало разных идей. Разные люди читают   о MVC в разных местах берут с собой разные идеи и   описать их как «MVC». Если это не вызывает путаницы   затем получить эффект недоразумений MVC, которые развиваются через   система китайского шепота.

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

  

В основе MVC лежит то, что я называю разделенной презентацией. Идея   за Разделенной презентацией - сделать четкое разделение между   объектами домена, которые моделируют наше восприятие реального мира и   объекты представления, которые являются элементами GUI, которые мы видим на экране.   Объекты домена должны быть полностью автономными и работать без   ссылки на презентацию, они также должны иметь возможность поддерживать   несколько презентаций, возможно, одновременно.

Вы можете прочитать всю статью Фаулера здесь .

ответил Gnawme 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 01 Sep 2011 23:37:33 +0400 2011, 23:37:33
18

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

Модель - как мы представляем данные? Например, как мне перейти от моих объектов к постоянному хранилищу, например, к DB -> как сохранить объект «Пользователь» в базе данных?

Контроллер - что я делаю? Это действие, которое происходит, и что на концептуальном уровне необходимо выполнить. Например, на каких этапах я должен выполнить счет для выставления счета пользователю? Нотабене это может повлиять на любое количество объектов, но ничего не знает о том, как они сохраняются в БД.

Просмотр - как я могу сделать результат?

Проблема, которую я чувствую, что вы видите, - это то, что многие веб-приложения - это прославленный интерфейс CRUD (Create-Retrieve-Update-Delete) для БД. то есть контроллеру предлагается «добавить пользователя», а затем просто сообщает модели «добавить пользователя». Ничего не получается.

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

ответил Unk 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 01 Sep 2011 23:08:56 +0400 2011, 23:08:56
7

Вы не должны.

Позвольте мне перефразировать это. Вы должны использовать архитектуру, которая отделяет логику от ваших представлений. Если необходимо, вы должны использовать архитектуру, в которой используется контроллер (например, MVC), если требуется логика, которая не обязательно вписывается в модель (например, фрагменты URL-адреса для анализа дерева).

Исходя из CI и Yii, я подумал, что наличие специального контроллера - это действительно крутая идея. Однако при разработке приложений с надлежащими интерфейсами RESTful потребность в контроллере для обработки немодельной логики, по-видимому, уменьшается. Таким образом, при переходе на Django, а затем в Pyramid (ни одна из которых не полностью соответствует архитектуре MVC), я обнаружил, что контроллер не был фактически обязательным компонентом для приложений, которые я создавал. Обратите внимание, что обе структуры имеют «контрольные» функции, такие как диспетчеризация URL-адресов в Pyramid, но это элемент конфигурации, а не среда выполнения (например, CController в Yii).

В конце дня важным really является разделение представления от логики. Это не только чистое дело с точки зрения реализации, но также позволяет инженерам FE /BE работать параллельно (при работе в командной среде).

(Боковое замечание: профессионально я не разрабатываю веб-приложения, поэтому может быть что-то, что мне не хватает)

ответил Demian Brecht 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 01 Sep 2011 23:06:54 +0400 2011, 23:06:54
1

Да, терминология на этом - беспорядок. Трудно говорить, потому что вы никогда не понимаете, что означает .

Что касается отдельного контроллера, причина может зависеть от той версии контроллера, о которой вы говорите.

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

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

ответил psr 2 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 02 Sep 2011 03:06:27 +0400 2011, 03:06:27
0

Проще говоря: разделение проблем. Помимо всех разговоров о «правильном» способе делать вещи, имея более чистый код и т. Д., Вы можете просто сказать, что MVC позволяет вам более легко повторно использовать ваш код. В основном вы программируете свои модели и контроллеры, и вы можете использовать их невнятно в веб-приложении, настольном приложении, службе и везде без особых усилий.

ответил AJC 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 01 Sep 2011 23:49:57 +0400 2011, 23:49:57
-3

Ну, основная причина использования структуры MVC проявляется в отраслевой установке, где для разработки любого приложения используется один рабочий процесс, одна модель. Таким образом, в случае, если проект переходит от одного модуля организации к другой, гораздо легче обеспечить лучшее понимание сценария работы. Он включает в себя ясность работы.
Хотя у вас, как у человека, будет другой подход к вашему приложению, вы, когда будете работать совместно с коллегой, сначала обсудите и приземлитесь на общепринятую модель двумя (вы и ваш сотрудник). И в этом случае он отделяет обязанности, назначенные вам и вашему партнеру, соответственно с отличительной маржой.

ответил ikartik90 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 01 Sep 2011 23:29:12 +0400 2011, 23:29:12
-3

Я думаю, что MVC используется просто модным словом теоретиков, которые являются менеджерами. Однако, сказав, что текущая итерация сети с использованием HTML5, отзывчивый дизайн и попытка создать единую линию программирования баз данных, которая будет работать в Интернете и на iPhone, поддаются общим идеям MVC. Веб-интерфейсная технология буквально движется со скоростью света прямо сейчас с JQuery, новыми итерациями CSS-управления, тогда как серверная сторона вещей движется в темпе улитки.

В конце концов, все на сервере действительно будет просто сервисами или «апплетами», которые будут передавать данные в интерфейс и в зависимости от того, какой у вас клиент, эти данные будут потребляться и отображаться по-разному. В этом смысле MVC имеет смысл.

В этом отношении я верю в настоящий реальный мир, MVVM - действительно лучший «шаблон» или что-то, что вы хотите назвать, чем контроллер, потому что контроллер всегда должен вернуться к модели, чтобы изменить представление и это медленно. В шаблоне MVVM ViewModel может мгновенно обновлять представление. Кроме того, модель MVVM продвигает дизайнеров проекта RESTful IMHO.

ответил Michael Barber 8 Maypm15 2015, 21:41:19

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132