MVC – проблема или решение? (перевод)

Repositories, Adapters, MVC со всеми родственниками, SOLID, RTFM…
Как (PHP) разработчик, эти слова бросаются на тебя со всех уголков Интернета. Я ненавижу это, с меня достаточно. Прекратите говорить мне, что делать и показать мне этих котят вместо этого.

Программное обеспечение решает проблемы

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

Проблемы разрешимы и решения для этих проблем становятся частью чего-то большего. Черный ящик, который удовлетворяет всем исходным требованиям. Но как мы решаем эти проблемы? Будет ли мое решение лучшим? Будут ли понимать другие разработчики (или я сам через 2 месяцы), что я тут делал?

Одно решение подходит всем

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

Так почему же MVC лучше? Обычно отвечают:

• Снижение сложности кода
• Повторное использование кода
• Повышение гибкости 
• Разделенный код 
• Круто, звучит красиво, но ... 

Это правда? 

Неужели в других моделях не хватает этих вещей? 

Ответ: нет.

MVC не решает проблему сложности кода. Он не решает проблему повторного использования кода или проблему не-гибкости. И он не гарантирует разделенность кода. 

Разработчики гарантируют снижение сложности кода. Это мы кодеры, программисты, разработчики и художники, которые пишут гибкий, разделенный и повторно используемый код. Мы столь же нуждаемся в MVC, сколько jQuery нуждается в document.getElementById(). Мы строили большие системы еще до того как услышали об MVC и будем продолжать строить без его использования.

Не забывайте что MVC является шаблоном, а не решением. Он стоит в очереди со всем остальными шаблонами проектирования как Адаптеры, Фабрики, Одиночки, Модули, Переводчики и Наблюдатели ...

Шаблоны не решают проблем, они помогают нам

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

Каждый паттерн имеет свои достоинства и недостатки и предназначен для решения той или иной ситуации. Шаблон фабрика, например, действительно хорош на создания объектов. Шаблон модуль помогает нам написать программные модули на языке, который не дает (или только частично) поддержку модулей (например, JavaScript). Сила паттерна наблюдатель является обработка событий, а MVC обеспечивает нас разделенными макетами, манипуляцией с данными и контроллерами.

Но MVC сильно злоупотребляют, и вот почему:

Где то и кто то решил что это лучший подход для PHP приложений доступных из браузера и всех остальных. Потом добавили правило что Модель должна быть 1 в один с таблицей в БД, а контроллер должен быть тонким и представление должно использовать шаблонизатор, который собирается с помощью PHP.

Затем кто-то отметил, что "тонкая контроллер" не всегда лучший подход. Таким образом, они создали правила для жирных контроллеров и тонких моделей.

Через некоторое время MVC показался нам бедным и мы породили HMVC, MVA, MVP, MVVM, PAC…

MVC является новым Singletone (или IE8)

Печально, но MVC не единственный шаблон которым злоупотребляют. Как Кейт красиво указывает: 

Нам нужно что-то, что выглядело как глобальная и действовал как глобальная, но не был действительно глобальным.

Внезапно Singletone начал показываться везде в нашем коде. Вы могли бы написать дерьмовый код без людей, жалующихся на использование глобальной $var. Вместо этого мы использовали шаблон Singleton, Global::getInstance()->var и назвал его OO.

Шаблоны это круто, разработчики нет

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

Поэтому, пожалуйста, я прошу вас. Не злоупотребляйте патернами.

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

Возникли проблемы разделения MySQL от вашего PHP? Вы пишете SELECT * FROM в HTML? MVC, вероятно, поможет вам, или, может быть многоуровневая архитектура лучше подходит для вас.

Проблемы с отложенной загрузкой / чтения данных конфигурации? Singletone может помочь вам.

Создание объектов является занозой в вашей заднице? Шаблон Фабрика поможет вам поддерживая DRY.

Не получается связать 2 сервиса с остальными? Адаптеры помогут вам.

Выводы

В зависимости от ситуации, и проблемы, различные модели могут помочь вам написать надежный, защищенный и понятный код. Только будьте осторожны, используя их - если вы ловите себя с использованием шаблона MVC для одного пагинатора, CTRL + A - Del.

Оригинал статьи: http://www.sitepoint.com/mvc-problem-solution/