MVC архитектурный образец

Question

Я некоторое время занимался Java и Ruby (и использовал фреймворки), и я знаю, что MVC - это способ отделить код. Дело в том, я думаю, что никогда не использовал это так, как должно.

Первый вопрос: бизнес-логика, что это значит? Означает ли бизнес-логика особую логику для этого приложения? Допустим, вы строите спутниковую систему. Является ли бизнес-логика кодом, который уникален для этой спутниковой системы и заставляет ее работать?

Что означает «домен»? Как и в доменной логике или домене как термине.

«Держите модель умной, контроллеры тонкими и выглядите тупыми». Это утверждение ясно указывает на то, что контроллеры, которые я загружаю со слишком большим количеством кода, являются неправильным способом его написания.

В качестве примера. Если у вас есть BankAccount класс. Тогда должен ли этот класс обеспечивать методы для поведения, такие как проверка и т. Д., А также метод получения / установки?

Что должен делать контроллер? Просто перенаправьте ввод / события в представлении на модель и, возможно, обновите представление (что имеет место в webframeworks).

Например, в Java и JPA у вас есть entityManager, который вы используете для поиска сущностей, возможно, что-то делаете с ними и т. Д. Если это entitymanager будет использовано в контроллере, или вы должны создать другой слой с именем, например, например. «Сервис», который использует контроллер. Но опять же, относится ли этот уровень сервера к модели в MVC? Как бы вы сделали это в Rails?

Мне кажется, я не совсем понимаю модель и концепцию контроллера.

Answer 1

Думайте о приложениях как о многоуровневых. Работая над каждым слоем, всегда думайте про себя: «Зависит ли этот слой от слоя над ним или он может работать независимо?» Это основа для хорошего приложения MVC.

При рассмотрении слоев в приложении в стиле MVC их несколько.

На мой взгляд, слоями (сверху вниз) являются представление, контроллеры, бизнес-логика и доступ к данным.

Представлением могут быть запросы JSP или даже AJAX от jQuery. Здесь пользователь взаимодействует с вашим приложением. Представление отправляет информацию на уровень бизнес-логики для выполнения работы.

Должны быть написаны контроллеры для сбора данных, отправляемых ему из представления, преобразования их таким образом, чтобы бизнес-логика могла их понять, а затем передачи информации на уровень бизнес-логики. Контроллеры также могут брать информацию, извлеченную из уровня бизнес-логики, преобразовывать ее и отправлять обратно в представление. Здесь не должно быть настоящей «бизнес-логики». Думайте об этом как о посреднике между представлением и уровнем бизнес-объектов. Это также отличное место для проверки данных, представленных представлением.

Бизнес-логика - это уровень, который вы можете найти посередине, обычно между контроллерами и уровнем доступа к данным. Это также можно назвать уровнем обслуживания. Это должно быть написано, чтобы ничего не знать о том, как это называется. Если написано правильно, вы можете использовать этот слой в автономном приложении. Здесь должно быть много умных приложений. Часто этот уровень просто вызывается уровнем доступа к данным и возвращает результаты обратно в контроллеры. Но здесь может происходить много других вещей, таких как манипулирование данными, вычисления, безопасность данных, проверка и т. Д.

Уровень доступа к данным должен быть написан таким образом, чтобы он принимал входные данные, извлекал соответствующие данные, преобразовывал их в пригодную для использования форму и возвращал ее. Этот слой не должен знать или заботиться о том, как он называется, и должен быть написан таким образом. Опять же, этот слой не должен знать, что он находится в веб-приложении или в отдельном приложении. Здесь есть много вариантов, чтобы сделать вашу жизнь проще в формах или в ORM (Object Relational Mapping). Если ваше приложение на шаг выше тривиального, вам следует подумать об его использовании.

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

Используя «BankAccount» в качестве примера:

«BankAccount» больше напоминает объект домена (представление данных в базе данных), чем класс, в котором есть логика. Обычно доменные объекты имеют только те поля, которые им нужны (номер счета, баланс и т. Д.) С геттерами и сеттерами.

Пользователь может войти на сайт своего банка. При входе в систему представление отправляет имя пользователя контроллеру (BankAccountController). Контроллер извлекает эту информацию из запроса и отправляет ее на уровень обслуживания (BankAccountService). Сервисный уровень отправляет эту информацию на уровень доступа к данным, который выполняет запрос к учетным записям BankAccounts, которые может иметь пользователь, и возвращает их на сервисный уровень, который возвращает их контроллеру. Контроллер будет манипулировать этой информацией таким образом, чтобы слой представления мог отображать их пользователю. Например, при переводе денег между учетными записями происходит аналогичная серия событий.

Надеюсь, это поможет ... дайте мне знать, если у вас есть еще вопросы или если что-то не понятно.

Edit:

Помимо ссылок, опубликованных другими пользователями, в Википедии есть небольшая, но довольно хорошая статья о MVC.

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller