Вы говорите: "счета - это модели" .На самом деле нет, они не являются.
A модель домена (также называемая модель слоя , или модель ) не является одним компонентом, нослой, состоящий из нескольких компонентов.Он абстрагирует реальный процесс и необходимые ресурсы.Другими словами, он моделирует бизнес-логику (представленную данными и особенно поведением).
Уровень модели может быть частью приложения или может использоваться несколькими приложениями.
Каждый из компонентов модели играет определенную роль.Это может быть сущность (например, объект домена ), объект значения , служба , преобразователь данных абстракция, хранилище абстракция, абстракция внешнего сервиса (например, электронной почты или платного сервиса) и т. Д. Под абстракциями я подразумеваю интерфейсы или абстрактные классы.Конкретные реализации не должны быть частью модели предметной области, а должны иметь другое внешнее пространство по сравнению с моделью, служащей инфраструктурными конструкциями.
Итак, ваши User, Account и Atm классы являются просто компонентами модели.Точнее, это сущности .
С другой стороны, контроллеры и представления являются компонентами уровня UI.
контроллеры (должны) взять на себя ответственность только откладывая (например, отправляя) выполнение пользовательского запроса на уровне модели .Точнее, к уровню обслуживания , который определен как пограничный уровень модели домена и представлен его компонентами обслуживания .Таким образом, определенный экземпляр службы внедряется в контроллер как зависимость.Контроллер передает ему текущий пользовательский ввод (данные) и вызывает его определенный метод, в котором определены необходимые этапы обработки пользовательских запросов.Экземпляр службы вместе с другими объектами уровня модели выполняет все эти шаги, чтобы обновить модель с помощью пользовательского ввода .Поэтому, имея в виду задачу диспетчеризации, метод контроллера должен быть небольшим и содержать 1-3 строки кода.
Представления (должны) получать (обновленные) данные из модели предметной области - , запрашивая их (например, извлекая из них данные) - и отображая их,Аналогично контроллерам, представления взаимодействуют с моделью через определенные сервисные компоненты.
Я использовал глагол «должен» , чтобы подчеркнуть тот факт, что существуют разные модели реализациислой пользовательского интерфейса.Реализация может использовать контроллеры и представления, как описано выше - оригинальный дизайн MVC.Другая реализация будет использовать контроллеры не только для обновления модели (через сервисы), но также для запроса ее (через сервисы), чтобы передать полученные данные в представление для отображения пользователю.Или реализация может даже не использовать сервисы вообще, что заставляет этапы обработки запроса пользователя быть определенными в контроллерах и / или представлениях.И так далее.Итак, вам решать, как вы решите реализовать слой UI .
Обратите внимание, что вы также можете иметь контроллеры и / или представления, названные как компоненты модели (User, Account, Atm и т. Д.).Но тогда вы должны использовать пространства имен , чтобы различать их все - рекомендуемый путь.В Java пространства имен управляются пакетами.
Некоторые ресурсы с более подробной информацией (в основном связанные с веб-MVC, с примерами на PHP):