различные стили реализации Model-View-Controller в Java

Question

// обновление 1: так что, к сожалению, в этой топи c не так много активности, на которую я рассчитывал - больше внизу

сначала: я знаю, что эта топи c часто переполняется и следовательно, страдают от личных мнений и, следовательно, часто закрываются как off-topi c. Поэтому я постараюсь сохранить объективность. Я надеюсь, что это не даст мне «запереться».

Когда вы смотрите на Википедию, в основном говорится следующее: пользователь напрямую взаимодействует с контроллером, контроллер управляет моделью, а модель обновляет представление. При поиске в Google можно найти множество других типов:

• один, например, утверждает, что модель всегда сама по себе и ничего не знает о других
• , другой говорит что контроллер является своего рода клеем, но модель и вид не знают друг друга

Это продолжается практически для любой комбинации этих трех в дополнение к некоторым «дополнениям». Итак, как я понимаю: кажется, на самом деле не один (правильный) способ реализации MVC, а скорее разные подходы, все следуют одному и тому же базовому принципу.

Итак, способ, которым я хочу попытаться сохранить это "цель": есть ли какая-то конкретная c причина для go того или иного подхода? Есть ли преимущество в использовании одного из трех в качестве клея для других? Или все знают друг друга в некотором роде?

Когда используется Swing, уже используется какая-то форма MVC - некоторый источник назвал его «model- (ui) делегат», где View и Controller объединены на основе модели. , Стоит ли пытаться воспроизвести этот стиль как стиль, уже работающий с Swing?

Возможно, чтобы немного осветить его: в настоящее время я хочу разработать клиент API для Mixer (да, у меня есть темы о YouTube и Twitch, но в настоящее время Микшер кажется лучшей платформой для меня и моих потребностей) и немного борется за то, как приблизиться к разделению данных (Модель), GUI (Представление) и всего клея между ними (Контроллер?). В прошлом, когда я писал некоторые из своих небольших инструментов, я не чувствовал себя лучше, чем так называемый код спагетти. Но поскольку я хочу опубликовать sh его (я уже начал с использования publi c GitHub repo) или предоставить его в качестве службы (чтобы другие использовали мой клиент в моем проекте), я решил структурировать его по некоторым установленным принципам .

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

Заранее спасибо и извиняюсь перед любыми модераторами, теперь могут подумать, что «не один из них».

// edit 1: Итак, хотя не было много активность в этой топике c в последние недели я ничего не делал, но продолжал немного «проводить исследования»: из того, что я обнаружил, я получил следующее: не важно, имеет ли дело только какое-то локальное приложение на основе GUI, но Кроме того, я планирую различные типы представлений и источников событий по сети, и сводится к соединению нескольких классов по принципу разделения Все они выполняют только одну конкретную задачу c. Я нашел несколько примеров, когда вид был виден только как GUI, другие также распространяли его на консоль и даже на принтеры. Таким образом, рассматривать представление как единственный источник ввода может быть не самой лучшей идеей, но рассматривать его как нечто, отображающее только данные. Вход контроллера на другой стороне также может быть реализован как GUI, и, возможно, даже объединен с View, отображающим данные, но должен быть как минимум модульным, чтобы его можно было взаимозаменять с другими типами.

Я хочу попытаться реализовать его на основе событий, чтобы «действия» происходили в зависимости от того, когда событие сработало (то, как событие генерируется, а затем может сработать, относится к другой топи c). Я видел много примеров использования паттерна Observer для этого - так что в основном это комбинация Observer и MVC (по крайней мере, насколько я их понял). Может ли это быть возможным способом реализации:

• некоторый вход для генерации входных событий (может быть GUI, может быть, консоль, может быть, сетевой вход), подключенный к контроллеру ввода
• модель содержит данные и логи c для их изменения, может быть также имеющий свой собственный контроллер модели
• вид как управляемый только выходом, которым управляет либо основное приложение, либо собственный контроллер вида вместо регистрации себя в качестве наблюдателя на модели
• общего контроллера приложения как склейка между другими контроллерами с некоторыми склеенными логами c

В этом плане запуск приложения basi c будет выглядеть так: main () сначала создает основной контроллер приложения с просто пустыми списками для всех остальных затем модель (и) (или контроллер модели, с помощью которой она создает модель) и связывают контроллеры модели с основным контроллером, и в конце вид, а также связывают его с главным контроллером. Наконец, после того, как все это сделано, вызывается какая-то «точка входа» на главном контроллере, чтобы запустить все это.

У кого-нибудь есть какой-нибудь вклад в эту идею?

Answer 1

Существует один шаблон, которому я следую в большинстве проектов, и вдохновленный Spring Boot MVC, SOA и многими средами пользовательского интерфейса, такими как JSF.

1 - Ваши взгляды, если таковые имеются, должны всегда Будучи тупыми компонентами, они брали данные с контроллеров, отформатированных и готовых к отображению, они не поддерживают состояние.

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

3- Уровень модели отвечает за состояние объектов домена, которые могут поступать из хранилища данных, например базы данных, после того, как они получили данные определенным образом. пригодны для обслуживания или применения CRUD-операций, их роль завершена, модель ничего не знает о контроллере или представлении, модели все равно, если их вообще нет.

4 - Один хороший подход к go заключается в инкапсуляции вашей основной бизнес-логики c в Службах, если это необходимо. Сервисы содержат основную бизнес-логику c, и вы можете следовать принципам SOA, разрабатывая хорошие сервисы наряду с принципами проектирования, такими как SOLID, DRY и некоторыми шаблонами проектирования. Сервисы всегда должны быть чистыми и хорошо спроектированными, чтобы приложение не отказывалось от изменений, они могли выполнять всю работу и предоставлять результаты, подходящие для любого пользовательского интерфейса, а не только для конкретного контроллера или интерфейса пользователя, поэтому вы должны следовать принципам SOA. 1009 *

Так в чем же разница между моделью и видом модели / контроллера? модель представления дает представлению то, что им нужно ... см. этот ответ для более ясного объяснения

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

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

Вам нужно много вещей, чтобы избежать анти-паттерна спагетти-кода. Если вам нужны хорошие ресурсы, чтобы узнать об этом, вы можете прочитать чистый код, книги по чистой архитектуре, а также некоторые шаблоны проектирования и методы рефакторинга из первоисточника шаблонов проектирования и / или refactoring.guru или любого другого источника, который вам удобен. Этот топи c настолько широк и может о многом рассказать.