Общие шаблоны проектирования для использования в веб-приложениях MVC
Я пытаюсь обучить некоторых парней созданию веб-приложений. Они понимают и используют MVC, но меня интересуют другие общие шаблоны, которые вы используете при создании веб-приложений.
Итак, какие шаблоны вы нашли, чтобы хорошо вписаться в надлежащее приложение MVC. Возможно, что-то для асинхронных процессов, запланированных задач, касающихся электронной почты и т.д. Что вы хотите, чтобы вы знали, чтобы искать или избегать?
Не то, чтобы это важно для этого вопроса, но мы используем ASP.NET и Rails для большинства наших приложений.
Ответы
Ответ 1
Как только вы попадете в MVC, может быть полезно изучить шаблоны за пределами книги "Банда четырех" и попасть в Мартина Фаулера " Шаблоны корпоративного приложения Архитектура".
Шаблон Registry может быть полезен для создания известных объектов по всей иерархии объектов. По сути, это замена для использования глобальных данных.
Многие фреймворки MVC также используют Front Controller и двухэтапный Просмотр.
"Модель" в MVC лучше всего разработана как шаблон Модель домена, хотя некоторые фреймворки (во главе с Rails) conflate Model с шаблоном ActiveRecord. Я часто советую, что связь между моделью и ActiveRecord должна быть HAS-A, а не IS-A.
Также читайте о ModelViewController в вики-репозитории паттерна Portland. Существует несколько хороших обсуждений MVC, объектно-ориентированных и других шаблонов, которые дополняют MVC, например Observer.
Ответ 2
Этот вопрос настолько открыт, что трудно дать правильный ответ. Я мог бы сказать вам, что шаблон Наблюдатель важен в MVC (и для веб-приложений), и это будет хороший ответ. Все существующие шаблоны проектирования распространены в большом веб-приложении. Для создания сложного объекта вам потребуется использовать Factory, а для доступа к некоторому разделу требуется несколько Фасад.
Если вы хотите больше "советов" или хорошей практики вместо шаблона проектирования, я бы предложил вам использовать IoC и использование хорошего Framework вместо начала с нуля. Я могу посоветовать вам объяснить преимущество наличия хорошего ORM, чтобы ускорить ваш уровень устойчивости (обычно может также исходить из Рамочной основы).
Ответ 3
Не смотрите на это с точки зрения того, какие шаблоны использовать с вашим подходом к развитию, но посмотрите на это как на то, как применять шаблоны на основе проблемных проблем. Архитектурные решения, принятые для проекта, дают такое же представление о том, какие шаблоны использовать, как диктует опыт других людей.
Тем не менее, я обнаружил, что я являюсь поклонником модели Provider, предлагая несколько вариантов для выполнения одной задачи с легкостью развертывания. Кроме того, шаблон Unit of Work отлично подходит для установления границ транзакций. Во многом, однако, архитектура и бизнес-потребности диктуют подход, который принимается для любого заданного изменения кода или новой разработки.
Насколько мне нравятся узоры, я всегда боюсь видеть их чрезмерными. Я лично видел людей, которые использовали их только ради их использования, и на самом деле это сделало код сложнее поддерживать и более тесно связать, чем следовало бы. Кроме того, хорошо знать обе стороны аргумента шаблонов. Знание хорошего шаблона должно быть округлено с помощью (обычно часто считающегося шаблоном) anti-pattern.
Ответ 4
Я бы, скорее всего, порекомендую какую-то инъекцию зависимостей (Inversion of Control). Вероятно, это один из самых важных дополнительных шаблонов.
