Где М в MVC?

Я пытаюсь реорганизовать свое приложение в MVC, но я застрял на М-части.

В приложении, поддерживаемом базой данных, модель реализована в коде приложения, верно?

Но тогда, что находится в базе данных - это не модель?

(Я не использую базу данных в качестве простого хранилища объектов - данные в БД являются активом предприятия).

Да, и модель в коде, и база данных являются «моделью».

Модель имеет отношение к тому, что ваше приложение «ЕСТЬ», а контроллер к тому, что оно «делает». Любой код, связанный с прямым сохранением в базе данных, считается моделью.

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

Trygve Reenskaug написал первоначальные статьи, описывающие паттерн MVC еще в 1978 году. Модель в его описании была объектной моделью, представляющей объекты, явления и концепции реального мира. В вашем сценарии приложения с поддержкой базы данных модель представляет собой проекцию ваших данных. Проще говоря, модель - это классы и их отношения, которыми занимается ваше приложение.

На практике в MVC обычно используются две модели: модель предметной области (что отображается в вашей базе данных) и модель приложения (также называемая моделью представления в современной терминологии). Модель приложения - это проекция модели предметной области, которая также содержит конкретные данные представления для визуализации представления. Этот подход называется MMVC . Контроллер напрямую взаимодействует с моделью предметной области и представляет модель приложения для представления. В шаблоне MVVM модель приложения и контроллер объединены.

1. Вам не нужна база данных для MVC. Если ваша модель общается с базой данных, то отлично. Он также может сохраняться в виде плоского файла или вообще не сохраняться.

2. Модель - это место, где данные хранятся в памяти вашего приложения. Вы также захотите использовать модель для проведения расчетов и проверки ее данных. Например, у вас есть модель FinancePayment со свойствами, такими как процентная ставка, срок и принцип. Вы можете добавить метод getMonthlyPayment () в свою модель для расчета ежемесячного платежа. Вы не хотели бы делать это в контроллере или представлении.

3. Представление должно быть достаточно тупым, либо не иметь никакой логики, либо использовать только простое связывание данных (см. Шаблоны пассивного представления и контролирующего контроллера на сайте Мартина Фаулера ). Представление вызывает события, когда пользователь что-то делает, например, нажимает кнопку.

4. Контроллер отвечает за обработку событий (запуск некоторого кода, когда пользователь нажимает кнопку «Сохранить»), а также за настройку свойств модели и указание модели загружать и сохранять себя (если используется постоянство). Контроллер не должен делать расчеты по данным модели. Однако в контроллере вы можете выполнять некоторые вычисления от имени представления, например, «if model.profit () <0 then widget.colour = 'red'"

5. Вы должны иметь возможность переключаться на версию своего приложения из командной строки, не меняя модели и не теряя функциональности моделей.

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

Модель - это код, который подключается к V и C во внешнем интерфейсе и к постоянному хранилищу (может быть что угодно, от файлов до баз данных SQL / NoSQL) во внутреннем интерфейсе. Это не только код, который загружается из БД и сохраняет в БД (что является одним из недоразумений модели), это код, который фактически выполняет всю работу «домена» - выбирает, фильтрует, изменяет, вычисляет, принимает решение по данные. Включает в себя всю не-UI логику приложения.

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

Модель обычно рассматривается как модель предметной области (грубо говоря, бизнес), а не как модель данных. Они могут выглядеть похожими, но они не полностью связаны друг с другом.

Представление должно быть моделью внешнего интерфейса приложения, а контроллер должен быть моделью потока от одного представления к другому.

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

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

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

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

But then, what is in the database -- is that not also the model?

Нет это не так. « Модель управляет поведением и данными домена приложения». Часто Модель подключается к базе данных, но это никоим образом не является требованием. Модель представляет собой новый слой между вашим приложением и базой данных. Бэкэнд может быть набором объектов Mock, XML или чего-либо еще, поддерживающего сохранение данных.

Разъединяя слои, вы даете себе гораздо большую гибкость, чтобы использовать лучшие практики модульного тестирования, сделать код более управляемым (EG SQL заменяется Oracle) и другие преимущества.

То же самое касается контроллера. MVC определяет контроллер как посредника между двумя уровнями. В MVC не определен «бизнес-уровень». Скорее, вы добавляете свои собственные. MVC не включает в себя все уровни, необходимые для создания большинства приложений. Это просто общее руководство для базовой структуры.

Эти разделения являются ключом к разрешению инверсии управления, чтобы функционировать.

База данных - это деталь реализации модели. Модель должна быть полной моделью предметной области и должна сочетать данные и процессы. Разделение должно проводиться между проблемами различий, а не между процессом и данными, связанными с этим процессом.

Смотрите также: http://martinfowler.com/bliki/AnemicDomainModel.html

На самом деле это очень просто, «Модель» представляет абстракцию для интерфейса данных. Поэтому:

• Базы данных рассматриваются как часть модели , но не сама модель
• Данные Модели могут поступать из баз данных, файлов, веб-сервисов или даже быть поддельными.
• Классы моделей в MVC, HMVC или аналогичных средах должны хранить запросы (см. Принцип «толстая модель, тощий контроллер» [ 1 ] [ 2 ] [ 3 ])

И - если я прав - именно поэтому, когда кто-то ссылается на модели вне контекста MVC, этот человек, скорее всего, ссылается на структуру данных (т.е. схему ).

Я думаю, что М содержат некоторую логику и хранить данные в БД. Контроллер вызывает, какой модуль должен быть выполнен, и этот модуль будет выполнять логику и сохранять данные в БД (возможно, имеет постоянный уровень), а затем этот модуль возвращает значение V.

M (odel) в MVC должен фиксировать модель бизнеса / домена в одном месте.

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

C (контроллер) в идеале должен заниматься только передачей информации бизнес-модели в представление (например, представление) и захватом пользовательского ввода из V (iew), чтобы инициировать изменения в состоянии модели.

Слой базы данных имеет дело (или, скорее, должен только иметь дело) с сохранением состояния модели в конкретный момент времени.

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

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

Взаимодействия между моделью и сохраненными данными могут происходить либо на отдельном слое данных, либо непосредственно в модели, что имеет место при использовании ORM (Object Relational Mapper). Другими словами, либо модель подключается напрямую к базе данных, либо передает свои данные в какой-то другой объект «доступа к данным», который подключается к базе данных.

ORM (Object Relation Mapper) сопоставляет поля в таблице базы данных с атрибутами вашего объекта модели, предоставляя методы получения и установки. В этом случае нет отдельного слоя данных, и модель несет прямую ответственность за сохранение своих данных.

Вот пример Ruby с ActiveRecordиспользованием популярного ORM:

class House < ActiveRecord::Base
end

house = House.new
house.price = 120000
house.save

Priceэто поле в housesтаблице, которое автоматически определяется с помощью ActiveRecordкоторого к объекту добавляются методы получения и установки. Когда saveвызывается, значение атрибута цены сохраняется в базе данных.

С моей точки зрения преимущество наличия уровня данных состоит в том, что вы получаете точку, в которой вы можете манипулировать данными, прежде чем они попадут в модель, модель меньше беспокоится, у нее меньше обязанностей. Например, вам может потребоваться объединить данные из нескольких несовместимых источников данных, это то, что ORM не может легко обработать.

Основным недостатком является еще один уровень абстракции для управления, если вам это не нужно, не беспокойтесь, будьте проще. Меньше движущихся частей, меньше ошибаться.

Да ты прав.

(Модель просмотра контроллера)

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

На практике представления и контроллеры MVC часто объединяются в один объект, потому что они тесно связаны. По данным MSDN

Контроллер интерпретирует ввод мыши и клавиатуры от пользователя, информируя модель и / или the view to change as appropriate.

Проверьте эту схему:

Например, код контроллера проверяет запрос данных и заставляет его возвращаться в представлении. Объекты контроллера вида привязаны только к одной модели; тем не мение,a model can have many view-controller objects associated with it.