Что такое модель в MVC

Я немного смущен тем, что именно ограничивается моделью. Я понимаю, что он работает с данными из базы данных и т.д. Может ли он использоваться для чего-нибудь еще? Возьмем, например, систему аутентификации, которая отправляет электронное письмо активации пользователю при регистрации. Где было бы наиболее подходящим местом для размещения кода для электронной почты? Будет ли модель подходящей... или лучше ли ее использовать в представлении, контроллере и т.д.?

ОТВЕТЫ

Ответ 1

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

Чтобы ответить на ваш вопрос конкретно

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

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

Вид в основном "В вашу учетную запись отправлено электронное письмо с подтверждением" или "Ваш адрес электронной почты недействителен". Таким образом, контроллер смотрит на модель и определяет выход для представления.

Ответ 2

Подумайте об этом так. Вы разрабатываете свое приложение, и знаете, согласно дорожной карте, что в версии 1 не будет ничего, кроме текстового интерфейса командной строки. версия 2 будет иметь веб-интерфейс, а в версии 3 будет использоваться какой-то gui api, такой как windows api или cocoa, или какой-то кросс-платформенный инструментарий. Это не имеет значения.

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

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

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

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

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

Итак, чтобы выяснить, идет ли что-то в модели или нет, задайте себе вопрос: "Если бы мне пришлось переписать это приложение для работы на платформе X, мне пришлось бы переписать эту часть?" Если да, то держите его вне модели. Если ответ отрицательный, он может войти в модель, если она является частью основной логики программы.

Этот ответ может быть не ортодоксальным, но это единственный способ, который мне когда-либо приходилось думать о парадигме MVC, которая не заставляет мой мозг угасать от моего уха от бессмысленного теоретического mumbo jumbo, что дискуссии о MVC полный.

Ответ 3

Отличный вопрос. Я задавал этот вопрос много раз в мои ранние дни MVC. Это трудный вопрос, чтобы ответить, но я сделаю все возможное.

Модель обычно представляет "данные" вашего приложения. Однако это не ограничивает вас базой данных. Ваши данные могут быть XML файлом, веб-ресурсом или многими другими. Модель - это то, что инкапсулирует и обеспечивает доступ к этим данным. На языке OOP это обычно представляется как объект или набор объектов.

В этом ответе я буду использовать следующий простой пример: я буду ссылаться на этот тип объекта как на Entity:

<?php
class Person
{
    protected $_id;
    protected $_firstName;
    protected $_lastName;
    protected $_phoneNumber;
}

В простейшем из приложений, скажем, приложение телефонной книги, этот Entity будет представлять Person в телефонной книге. Ваш код View/Controller (VC) будет использовать этот Entity и коллекции этих Entities для представления записей в телефонной книге. Возможно, вам интересно: "Хорошо. Итак, как я могу создавать/заполнять эти сущности?". Общей ошибкой новичков MVC является просто начать писать логику доступа к данным непосредственно в своих методах контроллера для создания, чтения, обновления и удаления (CRUD). Это редко бывает хорошей идеей. Обязанности CRUD для этих Сущностей должны находиться в вашей Модели. Я должен подчеркнуть: Модель - это не просто представление ваших данных. Все обязанности CRUD являются частью вашего слоя модели.

Логика доступа к данным

Два из более простых шаблонов, используемых для обработки CRUD, Table Data Gateway и Row Data Gateway. Одна распространенная практика, которая, как правило, "не очень хорошая идея", заключается в простое, чтобы объекты Entity напрямую расширяли ваши TDG или RDG. В простых случаях это прекрасно работает, но оно раздувает ваши сущности с ненужным кодом, который не имеет ничего общего с бизнес-логикой вашего приложения.

Другой шаблон, Active Record, ставит всю эту логику доступа к данным в Entity по дизайну. Это очень удобно и может очень помочь с быстрым развитием. Этот шаблон широко используется в Ruby on Rails.

Моя личная модель выбора и самая сложная, это Data Mapper. Это обеспечивает строгое разделение логики доступа к данным и сущностей. Это делает для сумасшедших бизнес-логических сущностей. Для реализации Data Mapper обычно используется TDG, RDG или даже шаблон Active Record, чтобы обеспечить логику доступа к данным для объекта mapper. Очень хорошая идея реализовать Identity Map, который будет использоваться вашим Data Mapper, чтобы уменьшить количество запросов, которые вы делаете на ваш носитель данных.

Модель домена

Модель домена - это объектная модель вашего домена, которая включает в себя поведение и данные. В нашем простом приложении для телефонной книги это был бы очень скучный класс Person. Возможно, нам понадобится добавить еще больше объектов в наш домен, таких как "Работодатель" или "Адреса". Они станут частью модели домена.

Модель домена совершенна для сопряжения с шаблоном Data Mapper. Ваши контроллеры просто использовали Mapper (s) для CRUD для объектов, необходимых для представления. Это позволяет вашим контроллерам, представлениям и объектам полностью агностически относиться к среде хранения. Это также позволяет использовать разные Mappers для одного и того же объекта. Например, у вас может быть объект Person_Db_Mapper и объект Person_Xml_Mapper; Person_Db_Mapper будет использовать вашу локальную БД в качестве источника данных для создания сущностей, а Person_Xml_Mapper может использовать файл XML, который был выгружен кем-то или вы получили удаленный вызов SOAP/XML-RPC.

Уровень обслуживания

Шаблон Service Layer определяет границу приложения со слоем услуг, который устанавливает набор доступных операций и координирует ответ приложения в каждой операции, Я думаю об этом как о API для моей модели домена.

При использовании шаблона Service Layer вы инкапсулируете шаблон доступа к данным (Active Record, TDG, RDG, Data Mapper) и модель домена в удобную единую точку доступа. Этот уровень обслуживания используется непосредственно вашими контроллерами, и если хорошо реализовано, это удобное место для подключения других интерфейсов API, таких как XML-RPC/SOAP.

Уровень обслуживания также является подходящим местом для размещения логики приложения, Если вам интересно, какая разница между прикладной и бизнес-логикой, я объясню.

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

  • Каждый человек должен иметь адрес
  • Ни один человек не может иметь номер телефона более 10 цифр
  • При удалении Лица их адрес должен быть удален.

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

  • Когда человек удаляется по электронной почте, системный администратор
  • Показывать максимум 5 человек на страницу

Не имеет смысла добавлять логику для отправки электронной почты в нашу модель домена. Мы закончили бы подключение нашей модели домена к любому классу рассылки, который мы используем. Мы также не хотели бы ограничивать наш Data Mapper для извлечения только 5 записей за раз. Наличие этой логики в Уровне обслуживания позволяет нашим потенциально различным API-интерфейсам иметь свою собственную логику. например Веб может получить только 5, но XML-RPC может получить 100.

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

Ресурсы

Каждый серьезный разработчик должен иметь эти книги в своей библиотеке:

  • Шаблоны проектирования: элементы многоразового объектно-ориентированного программного обеспечения.
  • Шаблоны архитектуры корпоративных приложений
  • Разработка под управлением домена: проблема сложности в сердце программного обеспечения.

Ответ 4

Подумайте об этом так:

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

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

Итак, я бы сказал, что вы хотите поместить код для электронной почты в контроллер.

Ответ 5

MVC обычно предназначен для дизайна пользовательского интерфейса. Я думаю, в вашем случае простой шаблон Observer был бы идеальным. Ваша модель может уведомить слушателя о том, что пользователь зарегистрирован. Этот слушатель затем отправит электронное письмо.

Ответ 6

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

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

Электронный адрес активации должен быть отправлен в результате успешной операции сохранения контроллером.

Псевдокод:

public class RegisterModel {
    private String username;
    private String email;
    // ...
}

public class RegisterAction extends ApplicationController {
    public void register(UserData data) {
        // fill the model
        RegisterModel model = new RegisterModel();
        model.setUsername(data.getUsername());
        // fill properties ...

        // save the model - a DAO approach would be better
        boolean result = model.save();       

        if(result) 
            sendActivationEmail(data);
    }
}

Более подробную информацию о концепции MVC можно найти здесь:

Ответ 7

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