Что точно является моделью в MVC

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

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

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

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

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

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

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

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

Думайте об этом так

Модель - это предметно-зависимое представление данных, на которых работает приложение.

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

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

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

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

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

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

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

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

Двумя простыми шаблонами, используемыми для обработки CRUD, являются Шлюз данных таблицы и Шлюз данных строк ]. Одна распространенная практика, которая, как правило, «не лучшая идея», заключается в том, чтобы ваши объекты Entity напрямую расширяли ваш TDG или RDG. В простых случаях это работает нормально, но при этом ваши Entities раздуваются ненужным кодом, не имеющим ничего общего с бизнес-логикой вашего приложения.

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

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

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

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

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

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

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

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

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

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

• У каждого человека должен быть адрес
• Ни один человек не может иметь номер телефона длиннее 10 цифр
• При удалении человека его адрес должен быть удален

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

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

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

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

Ресурсы

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

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

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

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

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

Псевдокод:

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 можно найти здесь :

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