Разделение проблем; MVC; почему?

Вот подход, который я проявляю при создании веб-сайтов в PHP использование MVC/separation шаблона проблем:

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

• Модели - Классы PHP. Я добавляю методы к ним, чтобы выбрать и сохранить данные. Каждая модель представляет отличный тип объекта в системе: пользователи, страницы, сообщения в блоге
• Представления - шаблоны Присяжного острослова. Это - то, где HTML живет.
• Контроллеры - классы PHP. Это мозги приложения. Обычно URL в сайте вызывают методы класса. example.com/user/show/1 вызвал бы $user_controller-> шоу (1) метод. Контроллер выбирает данные из модели и дает его представлению.

Каждая из этих частей имеет определенное задание или "беспокойство". Задание модели состоит в том, чтобы предоставить чистый интерфейс данным. Обычно данные сайта хранятся в базе данных SQL. Я добавляю методы к модели для добывания данных и сохранения данных в.

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

Задание контроллера состоит в том, чтобы выступить в качестве посредника между пользователем, моделью и представлением.

Давайте посмотрим на пример того, как они объединяются и где преимущества лежат:

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

posts
id date_created title body hits

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

$sql = "SELECT * FROM posts ORDER BY hits DESC LIMIT 5";
$result = mysql_query($sql);

while ($row = mysql_fetch_assoc($result)) {
    echo "<a href="post.php?id=$row['id']">$row['title']</a><br />";
}

Этот отрывок довольно прост и работает хорошо если:

1. Это - единственное место, которое Вы хотите показать самым популярным сообщениям
2. Вы никогда не хотите измениться, как это смотрит
3. Вы никогда не решаете изменить, каково "популярное сообщение"

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

Что, если Вы хотите обновить разметку для домашней страницы для добавления класса "нового сообщения" к сообщениям, которые были созданы сегодня?

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

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

Проявление подхода MVC и осуществление разделения проблем в рамках Вашего приложения могут смягчить эти проблемы. Идеально мы хотим выделить его в три области:

1. логика данных
2. прикладная логика
3. и логика дисплея

Давайте посмотрим, как сделать это:

Мы запустим с модели. У нас будет a $post_model класс и дает ему названный метод get_popular(). Этот метод возвратит массив сообщений. Дополнительно мы дадим ему параметр для определения количества сообщений для возврата:

post_model.php

class post_model {
    public function get_popular($number) {
        $sql = "SELECT * FROM posts ORDER BY hits DESC LIMIT $number";
        $result = mysql_query($sql);
        while($row = mysql_fetch_assoc($result)) {
            $array[] = $row;
        }
        return $array;
    } 
}

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

home_controller.php

class home_controller {
    $post_model = new post_model();
    $popular_posts = $post_model->get_popular(10);

    // This is the smarty syntax for assigning data and displaying
    // a template. The important concept is that we are handing over the 
    // array of popular posts to a template file which will use them 
    // to generate an html page
    $smarty->assign('posts', $popular_posts);
    $smarty->view('homepage.tpl');
}

Теперь давайте посмотрим то, на что было бы похоже представление:

homepage.tpl   

{include file="header.tpl"}

 // This loops through the posts we assigned in the controller
 {foreach from='posts' item='post'} 
    <a href="post.php?id={$post.id}">{$post.title}</a>
 {/foreach}

{include file="footer.tpl"}

Теперь мы имеем основные части нашего приложения и видим разделение проблем.

Модель касается получения данных. Это знает о базе данных, это знает об операторах LIMIT и SQL-запросах. Это знает, что должно возвратить хороший массив.

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

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

Также важно упомянуть то, что не знает каждая часть.

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

Контроллер и представление не знают, что сообщения хранятся в базе данных SQL.

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

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

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

1. Покажите популярные сообщения на боковой панели на подстраницах
2. Выделите новые сообщения с дополнительным классом CSS
3. Измените базовое определение "популярного сообщения"

Для показа популярных сообщений на боковой панели, мы добавим два файла наша подстраница:

Контроллер подстраницы...

subpage_controller.php

class subpage_controller {
    $post_model = new post_model();
    $popular_posts = $post_model->get_popular(5);

    $smarty->assign('posts', $popular_posts);
    $smarty->view('subpage.tpl');
}

... и шаблон подстраницы:

subpage.tpl

{include file="header.tpl"}

<div id="sidebar">

 {foreach from='posts' item='post'}
    <a href="post.php?id={$post.id}">{$post.title}</a>
 {/foreach}

</div>

{include file="footer.tpl"}

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

Теперь, на домашней странице мы хотим выделить новые сообщения. Мы можем достигнуть этого путем изменения homepage.tpl.

{include file="header.tpl"}

 {foreach from='posts' item='post'}
    {if $post.date_created == $smarty.now}
        <a class="new-post" href="post.php?id={$post.id}">{$post.title}</a>
    {else}
        <a href="post.php?id={$post.id}">{$post.title}</a>
    {/if}
 {/foreach}

{include file="footer.tpl"}

Здесь представление обрабатывает всю новую логику для того, чтобы показать популярные сообщения. Контроллер и модель ничего не должны были знать о том изменении. Это - просто логика дисплея. Список подстраницы продолжает обнаруживаться, как он сделал прежде.

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

post_model.php

class post_model {
    public function get_popular($number) {
        $sql = "SELECT * , COUNT(comments.id) as comment_count
                FROM posts 
                INNER JOIN comments ON comments.post_id = posts.id
                ORDER BY comment_count DESC 
                LIMIT $number";
        $result = mysql_query($sql);
        while($row = mysql_fetch_assoc($result)) {
            $array[] = $row;
        }
        return $array;
    } 
}

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

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

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

Необходимо уделить много внимания тому, как Вы создаете свои модели. Какие интерфейсы они обеспечат (см., что ответ Gregory расценивает контракты)? С каким форматом данных контроллер и представление ожидают работать? Размышление об этих вещах заранее сделает вещи легче в будущем.

Кроме того, могут быть немного служебные при запуске проекта получить все эти части, сотрудничающие приятно. Существует много платформ, которые обеспечивают стандартные блоки для моделей, контроллеров, обрабатывая по шаблону механизмы, маршрутизацию URL, и т.д. См. много других сообщений на ТАК для предложений на платформах PHP MVC. Эти платформы разбудят Вас и выполнение, но Вы как разработчик отвечаете за руководящую сложность и осуществление разделения проблем.

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

Я не уверен, что могу привести Вас к воде Вы wat пить, но я думаю, что могу ответить на некоторые Ваши проблемы.

Первый, в MVC, модель и представление действительно имеют некоторое взаимодействие, но представление действительно связано с контрактом а не с реализацией. Можно переключиться на верхний регистр к другим моделям, которые придерживаются того же контракта и все еще быть в состоянии использовать представление. И, если Вы думаете об этом, это имеет смысл. У пользователя есть имя и фамилия. У него, вероятно, также есть имя входа в систему и пароль, хотя Вы могли бы или не могли бы связать это с "контрактом" того, каков пользователь. Точка, как только Вы определяете, каков пользователь, она вряд ли изменится очень. Вы могли бы добавить что-то к нему, но маловероятно, что Вы собираетесь устранить это часто.

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

 public class User
 {
    public string FirstName;
    public string LastName;
 }

Да, я понимаю, что общедоступные поля плохи.:-) я могу также использовать DataTable в качестве модели, пока он представляет FirstName и LastName. Это не может быть лучшим примером, но точка является моделью, не связывается с представлением. Представление связывается с контрактом, и конкретная модель придерживается того контракта.

я не услышал о каждом объекте, должен иметь его собственный UI. Существует по существу два типа объектов: состояние и поведение. Я видел примеры, которые имеют и состояние и поведение, но они обычно находятся в системах, которые не являются очень тестируемыми, который я не люблю. В конечном счете каждый объект состояния должен быть представлен некоторой форме UI, чтобы не вынуждать людей IT обработать все обновления непосредственно в хранилище данных, возможно, но иметь их собственный UI? Я должен был бы видеть, что записанный в объяснении, чтобы попытаться понять то, что делает пользователь.

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

До книг по пониманию ООП, я склонен любить книги по шаблонам, поскольку они - более практические способы понять понятия. Можно найти материал краткой информации по сети. Если Вы хотите книгу шаблона агностика языка и думаете немного гиковатые, Банда Четыре заказывают, хорошее место для запуска. Для более творческих типов я сказал бы, Возглавляет Шаблоны разработки.

Проблема с идеей, что все Ваши объекты знают, как отобразить себя, состоит в том, что каждый объект может только быть отображен одним способом. Что происходит, если Вы хотите обеспечить представление детали пользователя и сводное представление. Что происходит, если Вы хотите отобразить представление, которое объединяет много объектов (пользователи и их связанные адреса, например). Если Вы разделяете свои бизнес-объекты (пользователи) от вещей, которые знают, как отобразить их тогда, у Вас больше нет кода для записи, Вы просто разделяете его в различные места.

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

ТВЕРДЫЕ принципы обеспечивают некоторое хорошее обоснование для этого, здесь относительно краткий взгляд на них. Я боюсь, что у меня нет книги для вручения, который подводит итог ее хорошо, но опыт учил меня, что легче написать новый код, чем она должна обновить старый код, и таким образом, проекты, которые способствуют маленьким модульным классам, которые включаются вместе для достижения того, что необходимо, в то время как тяжелее разработать впереди, намного легче поддержать в конечном счете. Замечательно быть в состоянии записать новый рендерер для пользовательского объекта, никогда не имея необходимость копаться во внутренностях того объекта.

кто-либо может выдвинуть аргумент [...], который объясняет, почему MVC является хорошей идеей?

Это сохраняет Вас нормальными, помогая Вам помнить то, что делает Ваш код, потому что они изолируются друг от друга.

• Рассматривают объем кода, который вошел бы в тот единый класс, если Вы хотите представить ту же информацию не только как HTML на UI, но и как часть RSS, JSON, сервиса отдыха с XML, [вставляет что-то еще].
• Это - текучая абстракция, означая, что это пытается дать Вам смысл, что это будет единственная часть, которая будет когда-либо знать, что данные, но это не может быть полностью истиной. Позволяет говорят, что Вы хотите предоставить услугу, которая будет интегрироваться с несколькими внешними третьими лицами. Вам будет действительно нелегко вынуждать их использовать Ваш определенный язык для интеграции с сервисом (поскольку это - класс единственная часть, которая может когда-либо данные, которые он использует), или если в другой руке Вы представляете некоторые ее данные, Вы не скрываете данные из тех сторонних систем.

Обновление 1: я дал общий вид на целую статью и быть старой статьей (99), это не действительно о MVC, поскольку мы знаем это сегодня по сравнению с объектно-ориентированным, ни имеет аргументы, которые являются против SRP.

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

Btw, у меня был флэшбэк с битом RMI. Так или иначе в том примере Вы видите, что он связывается с коммуникацией mecanism. Тем не менее каждый вызов метода удаленно обрабатывается. Я думаю, что он был также действительно обеспокоен на разработчиках, имеющих код, что вместо того, чтобы получить отдельный объект и воздействовать на возвращенную информацию, имел много маленьких, Заставляют вызовы получать тонны различных сведений.

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

Я не знаю хороших книг по предмету MVC, но на основе моего собственного опыта. В веб-разработке, например, много раз Вы работаете с разработчиками и иногда dbas. Разделение логики от представления позволяет Вам работать с людьми с различными наборами навыков лучше, потому что разработчик не должен очень о кодировании и наоборот. Кроме того, для понятия DRY можно сделать код менее повторяющимся и легче поддержать. Ваш код будет более допускающим повторное использование и сделает Ваше задание намного легче. Это также сделает Вас лучшим разработчиком, потому что Вы будете становиться более организованными и думать о программировании по-другому. Таким образом, даже если необходимо работать над чем-то, что не является MVC, у Вас мог бы быть другой подход к проектированию проекта, потому что Вы понимаете понятия MVC.

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