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

Question

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

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

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

Answer 1

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

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

Во многих средах MVC также используются Фронт-контроллер и Двухэтапное представление .

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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