Понимать архитектуру приложения MVC - PullRequest
3 голосов
/ 18 января 2012

Существует множество статей, объясняющих проект архитектуры приложения MVC, некоторые содержат бизнес-уровни, доменные уровни и т. Д.

Я хотел бы знать все термины и что должно быть внутри этого уровня?1003 *

Presentation.Web: приложение MVC находится здесьБизнес. Домен: ??Infrastructure.Data: ??

Какие еще уровни должны быть там, и как их использовать для создания идеальной архитектуры приложения MVC?

Ответы [ 3 ]

4 голосов
/ 18 января 2012

Эта хорошая статья Рассела Иста может вам помочь - http://russelleast.wordpress.com/2009/04/04/aspnet-mvc-defining-an-application-architecture/

2 голосов
/ 18 января 2012

Я попытаюсь объяснить это в технологически нейтральном формате:

MVC сокращенно для модели, вида, контроллера.

===========================================

Модель - это не девушка / мальчик, спускающаяся по лестнице, демонстрирующая модную одежду. Но это объект, который содержит ценные свойства (данные)

Например: В RPG (ролевая игра) каждый персонаж имеет такие характеристики, как здоровье, магия, атака, защита, уклонение, точность и т. д.

Эти характеристики называются свойствами в классах. Персонаж действует как класс, содержащий все эти свойства.

===========================================

Теперь, говоря о Виде, Вид - это то, что отображается в конкретной модели.

Например: У нас есть строка состояния, отображающая общее и текущее состояние здоровья.

Некоторым может быть интересно увидеть форму сердца, представляющую здоровье вместо красной полосы.

Разработчик начинает создавать другое представление, но все еще использует ту же модель. Это говорит о возможности повторного использования!

Вы повторно используете одну и ту же модель для отображения ее свойств разными способами!

============================================

Для контроллера это место, где определяется ваша бизнес-логика. Бизнес-логика (или также известная как «забавная» часть кодирования) это место, где вы определяете некоторый код для управления свойствами в модели и отправьте их на просмотр.

Например: Итак, давайте предположим, что у героя полное здоровье, Враг атакует его ...

Контроллер (у которого есть доступ к модели) манипулирует вашим Здоровье персонажа путем вычитания текущего здоровья из общего полученного урона от вражеской атаки.

Когда ваш персонаж выпивает зелье здоровья, контроллер увеличивает текущее здоровье вашего персонажа.

==========================================

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

Или

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

Вы также можете посмотреть эту ссылку

0 голосов
/ 18 января 2012

Может объяснить следующее:

Архитектура MVC

Основной целью архитектуры MVC является отделение бизнес-логики и данных приложения от данных презентации для пользователя.

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

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

1). Модель: объект модели знает обо всех данных, которые должны быть отображены. Это модель, которая знает обо всех операциях, которые могут быть применены для преобразования этого объекта. Он представляет только данные приложения. Модель представляет корпоративные данные и бизнес-правила, регулирующие доступ к этим данным и их обновление. Модель не знает о данных презентации и о том, как эти данные будут отображаться в браузере.

2). Представление: представление представляет презентацию приложения. Вид объекта относится к модели. Он использует методы запроса модели для получения содержимого и его визуализации. Представление не зависит от логики приложения. Это остается тем же самым, если есть какая-либо модификация в бизнес-логике. Другими словами, мы можем сказать, что ответственность за поддержание согласованности в представлении при изменении модели лежит на нем.

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

Источник: http://www.roseindia.net/struts/mvc-architecture.shtml

...