Общие шаблоны проектирования для использования в веб-приложениях MVC

Скорее всего, я бы также порекомендовал какую-то инъекцию зависимостей (инверсия управления). Вероятно, самый важный дополнительный «шаблон» для использования.

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

Если вы хотите больше «подсказок» или хорошая практика вместо шаблон дизайна, я бы посоветовал вам использовать IoC и использовать хороший Рамки вместо того, чтобы начинать с нуля. Я могу предложить вам объяснить преимущества наличия хорошего движка ORM, который также ускоряет ваш уровень сохраняемости (обычно это также можно сделать из Framework).

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

Тем не менее, я обнаружил, что я поклонник модели Provider, поскольку у меня есть несколько вариантов выполнения одной задачи с добавлением простоты развертывания. Кроме того, шаблон Unit of Work отлично подходит для установки границ транзакций. Однако в значительной степени архитектура и бизнес-потребности диктуют подход, применяемый к любому конкретному изменению кода или новой разработке.

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

Как только вы попадете в MVC, может быть полезно изучить шаблоны, выходящие за рамки книги «Банда четырех», и перейти к книге Мартина Фаулера «Паттерны архитектуры корпоративных приложений».

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

Многие инфраструктуры MVC также используют шаблоны Передний Контроллер и Двухэтапный просмотр.

«Модель» в MVC лучше всего спроектирована как шаблон Модель домена, хотя в некоторых фреймворках (во главе с Rails) объединять является моделью с шаблоном ActiveRecord. Я часто говорю консультировать, что связь между моделью и ActiveRecord должна быть HAS-A, а не IS-A.

Также прочтите о ModelViewController в вики Portland Pattern Repository. Есть хорошее обсуждение MVC, объектной ориентации и других шаблонов, дополняющих MVC, таких как Наблюдатель.