Структура приложения MVC

Question

Итак, я новичок в MVC и прочитал о нескольких десятках подобных вопросов о SO и некоторых блогах. Я не могу понять, как структурировать мое приложение. Либо я не получаю, либо люди, похоже, имеют разные мнения о том, как это сделать. Итак, вот мой конкретный, простой пример: экран входа в систему и экран создания учетной записи.

Из моего понимания я должен иметь следующее:

зрения Простой в этом случае два вида

модели Две вид модели. Логин имеет имя пользователя и пароль. Регистрация имеет имя пользователя, пароль, адрес электронной почты и т. Д. Только свойства не имеют методов.

контроллер Строит вид модель с помощью вызова службы слоя как CreateUser()

бизнеса/услуги отдельного проекта. Имеет методы взаимодействия с базой данных и применения бизнес-логики. Вызывается контроллером, который массирует вывод в формат модели просмотра. Этот проект имеет свои собственные модели/классы, не привязанные к определенному виду. CreateUser() в этом слое вызовет хранимую процедуру на db

Это правильный поток? А также при возврате данных с бизнес-уровня я не должен использовать модели представления. Итак, я создаю другой набор моделей на стороне бизнеса, которые напоминают логические сущности в db?

Answer 1

Звучит разумно. Вопрос о отдельных моделях и моделях просмотра является общим советом, чтобы избежать жесткой связи между вашим сервисом и вашим пользовательским интерфейсом. Это означает, что несколько приложений могут использовать сервисы, даже если их экраны пользовательского интерфейса отличаются. Однако я считаю, что в некоторых случаях имеет смысл пропустить модели просмотра, если они станут зеркальными изображениями моделей. Я только склонен создавать модели представления, если они добавляют какую-то ценность, когда дело доходит до подготовки данных для представления (форматирование и т. Д.).

Однако некоторые могут утверждать, что вы всегда должны создавать модели просмотра - даже те, которые отражают модель. Я также могу понять этот аргумент, поскольку он связан с тем, чтобы избежать взаимодействия между пользовательским интерфейсом и сервисом, что позволяет вам развивать сервис без изменения цепочки в пользовательском интерфейсе. Вы должны принять решение о том, насколько важно это для вас, поскольку это происходит за счет уровня, который «переправляет» значения между одинаковыми объектами.