Архитектуры OOD (Object-Oriented-Design) и MVC (Model-View-Controller) стали основными продуктами современного дизайна программного обеспечения. Тем не менее, у меня недавно была интересная дискуссия о том, как архитектуры MVC используют (и, возможно, даже нарушают) принципы OOD. Эта возможность на самом деле довольно интригующая, поскольку как OOD, так и MVC предназначены для достижения многих из тех же целей: разделения проблем и повторного использования программного обеспечения. Но вопрос, который я задаю: Являются ли эти две стратегии проектирования в прямом противоречии друг с другом?. Как я уже использовал, на практике я начинаю думать: вполне возможно, да.
Я так говорю, потому что: Обеспечение строгого разделения между моделями, представлениями и контроллерами часто приводит к архитектуре, где модели реализованы как немые контейнеры, которые могут управляться только через внешние контроллеры. Я утверждаю, что это прямо противоречит одному из главных принципов объектно-ориентированного проектирования: где объекты содержат операции, которые выполняют необходимые операции и инкапсулируют их по мере необходимости. Например, в чистой объектно-ориентированной архитектуре гипотетический класс File будет содержать такие методы, как open() и save(). MVC предполагает, что у нас есть два класса File и FileManager (такие, что позже содержит методы open() и save()). Для меня: дизайн MVC довольно грязный. Если нужно создать более специализированный тип File (скажем, для обработки файлов, которые передаются по сети в open() или save()), нужно только подкласс File с классом (пусть ): StreamedFile. С MVC вам придется либо создать другой класс менеджера, либо усложнить дизайн исходного класса менеджера.
Из этого следует, что следует, что в более сложной системе MVC может иметь катастрофические последствия как для разделения проблем, так и для повторного использования кода. Или нет? Возможно, модели MVC могут быть реализованы без нарушения принципов OOD? Или MVC является изначально ошибочным подходом, который затрудняет внедрение программных систем с слабо связанными компонентами?
Напротив, здоровое использование MVC должно поощрять тощие контроллеры и модели жира, чтобы модели (объекты) находились там, где происходит действие (которое само поощряет инкапсуляцию и другие хорошие принципы ООП), а контроллеры просто существуют укажите определенные запросы в правильном направлении к объектам.
Ничто в MVC не говорит о том, что Model должно быть глупо (анемичная модель). Я считаю, что вполне уместно иметь богатые классы Model, которые устраняют необходимость "менеджеров".
В настоящее время популярной практикой является использование ViewModel для передачи данных в View. ViewModel - это в основном проекция вашего Model специально для конкретного View. Его можно рассматривать как Model с точки зрения View, фасад для богатого Model; поэтому, конечно, существует гораздо больше Model, чем просто ViewModel.
Я бы не назвал MVC архитектурой, которая испытывает ту же боль, что и OOD. MVC - это просто шаблон OOD, который может применяться в определенных проектах. Таким образом, он просто не конкурирует с OOD и его только одним из ваших инструментов для создания хорошего или плохого дизайна OOD. Подобно тому, как молот не конкурирует с хорошим мастерством в дереве, молот, как и MVC, является всего лишь инструментом в инструментальной панели craftsmans.
Это не шаблон, который облегчает плохой дизайн. Поскольку хороший дизайн OOD будет иметь хорошее разделение проблем, шаблон MVC может обеспечить это для вас, отделяя проблемы представления (представления) от логики приложения (контроллера) и более фундаментальной логики (модели) домена. Таким образом, это хороший шаблон OO, который часто применяется в пользовательских интерфейсах. Но есть и другие конкурирующие модели, которые можно было бы также рассмотреть при создании хорошего OOD.
У нас есть две формы MVC, Pull MVC и Push MVC (например, MVC на основе компонентов и Legacy MVC).
Push MVC фокусируется на разделении понятий, каждый набор контроллеров модели-просмотра обрабатывает некоторые аспекты приложения и может быть спроектирован и разработан некоторыми отдельными людьми. Когда система быстро развивается, она отлично работает, и добавление функций тоже легко. Повторное использование кода в больших системах становится ужасным. По существу, только модели повторно используются.
Pull MVC фокусируется на повторном использовании кода с помощью виджетов (компонентов представления), так что многие представления используют один и тот же код и настраивают только их виджеты. Что касается контроллеров, то общие методы контроллера абстрагируются и выполняются.
Это вопрос смешивания Pull и Push MVC в зависимости от характера и темпа программного обеспечения.