Обсуждение:Model-View-Controller

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Пожалуйста, добавляйте новые темы снизу


пересмотреть статью[править код]

Не позорьтесь, пожалуйста, пересмотрите статью.

  • model - это данные, объект (например, база данных);
  • view - это отображение данных для субъекта (например, html-страница для пользователя);
  • controller - обработчик событий субъекта (например пользователя, браузера и т.п.) в ответ на отображение данных (например, http-запрос на сервер за обновлённой html-страничкой).

В данной модели есть только такие 3 зависимости: model зависит от controller, view зависит от model, controller зависит от view. Именно поэтому данная поведенческая модель признаётся одной из лучших. Позволяет отделить представление, поведение и базу данных.

alexeysa@yandex.ru — Эта реплика добавлена с IP 77.220.177.52 (о) 18:38, 11 января 2009 (UTC)[ответить]

  • Шаблон MVC является абстракцией, которая применима не только к веб-разработкам, но и любым дригим системам. Она появилась в 1979 году, еще задолго до веб-интерфейсов.
  • Model - это программное описание модели данных. Работа с данными обычно не включается в модель (она выносится в отдельные классы, которые находятся около модели, но не являются её частью). В статье работа с данными их описание объединены в один компонент, что допустимо, т.к. это абстракция.
  • Model не зависит ни от чего. Она вообще не догадывается о существовании поведения и представления. Она только описывает структуру данных в понятном для программы виде.

Суммируя: статью пересматривать не стоит, т.к. она описывает именно абстракцию MVC, а не конкретную реализацию для веб-приложений. — Эта реплика добавлена участником Tigpa (ов) 15:22, 16 июня 2009 (UTC)[ответить]

"обобщенного MVC"[править код]

Может, все-таки различать обобщенный MVC и MVC на дженериках? А то это машинный перевод.
81.5.122.171 12:41, 3 ноября 2011 (UTC)[ответить]

Стоило бы поподробней написать для таких, как я.[править код]

Я, конечно, понимаю, что вы тут даете краткие справки, но мне казалось, что они должны отражать суть проблемы для рядового пользователя, который вполне мог бы понять, о чем идет речь. Но как видно, желание потролить кого-то победило здравый смысл и авторы разместили 3 абзаца, практически ничего не объяснив, плюс плюнули в зенд. Статьи про опытные танки, концепты машин и прочий весьма условно-полезный материал занимают не в примет больше места, чем один из самых используемых приемов программирования. Так неужели никто не потрудился написать толковую статью. Зачем вы вообще разместили этот шлак? — Эта реплика добавлена с IP 213.110.135.83 (о) 19:56, 5 июля 2011 (UTC)[ответить]

Как понимаете, тут вам никто ничем не обязан, поэтому грубить не надо. Лучше книжки почитайте по теории ООП и про архитектуру 87.245.157.51 14:19, 27 июля 2011 (UTC) я.[ответить]
Теперь понятнее стало ? Что неясно конкретнее ? --S.J. 04:28, 30 июля 2011 (UTC)[ответить]
а нахрена тогда всю эту фигню пишите? для кого? перед тёлками понтоватся? я подобную херню и в книге вычитаю. сюда идут за разъяснениями темы,вопроса, а не за тем же самым, что и в книге. тут один говорит книги почитай, ну я почитал. дальше та что? я не понял темы. прихожу на вики для разбора, а меня посылают читать книги, замкнутый круг ёпрст! вы сами то не лучше тех кто не понимает. в вики одни чмошники пишут то, что и в книге, а на хрена вам разбирать тему, всё, я написал статейку в вики, я ферзь.109.169.223.101 08:35, 12 октября 2015 (UTC)[ответить]
    • Лучше, наконец, скажите какая часть вам не ясна. Или оставьте свой контакт. Раз у вас есть книга (а у меня её, например, нет), то я могу объяснить вам куда в ней смотреть и как понимать, а вы, взамен, отправите мне сканы страницы с выходными данными и я, согласно правилам Википедии, впишу информацию в статью. У нас тут не хабрахабр, чтоб любой взял и написал урок по какой-то теме, простите. higimo@gmail.com -- пишите, я по любому вопросу отвечу.=) --higimo (обс.) 13:16, 16 октября 2015 (UTC)[ответить]
Вы - долбоyoб. 83.68.35.125 07:50, 10 ноября 2017 (UTC)[ответить]

Следует изменить изображение концепции MVC[править код]

Представленное в статье графическое изображение концепции MVC не соответствует действительности - на рисунке указана прямая связь от View к Model, в то время как Модель в принципе не должна догадываться о каком бы то ни было представлении. Предлагаю заменить на это изображение - MVC_Diagram --213.5.16.53 18:51, 16 октября 2011 (UTC)Johann[ответить]

Это не верная картинка. Не понятно что отражают стрелочки. Если это запросы и передачи данных, то картинка отображает MVP, а не MVC. Подтверждение: http://www.itu.dk/courses/VOP/E2005/VOP2005E/8_mvc_krasner_and_pope.pdf -- 85.26.168.122 07:49, 11 сентября 2012 (UTC) [SowingSadness on habrahabr.ru][ответить]
согласна с утверждением о том, что изображение в статье выбрано неудачно: Модель не должна знать о существовании Представления, а значит и не может его обновлять. изображение, предложенное на замену, в свою очередь тоже неточно, так как клиент, то есть, видимо, пользователь взаимодействует не с Контроллером, а с Представлением - то есть видит его и реагирует, используя его элементы. доступа напрямую к Контроллеру у пользователя быть не должно, как из соображения разделения ролей проекта, так и из соображений безопасности. я бы предложила заменить иллюстрацию на изображение с сайта Apple.com, хотя оно тоже неидеально https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/Art/model_view_controller_2x.png Paоla Celeste (обс.) 09:59, 31 июля 2019 (UTC)[ответить]

Ложная информация в статье[править код]

Ребят, простите, но фраза "контроллер выступает в роли класса с единственным методом run()" (выделено мной) - это чушь. То, что этот метод единственный, который описан в примере, не делает его единственным методом класса. Иначе - откуда взялись $this->getView(), $this->initTitle(), $this->checkAccess() и прочие? Если они унаследованы от Krugozor_Module_Advert_Controller_Common, то так и надо писать. Если не унаследованы - ну тады ваще сорри.

КМК, эта часть статьи - тупой копипаст с какой-то статьи/книги/чего-то еще, нужное подчеркнуть. В любом случае, это нужно исправлять. Как? Не знаю. Но что-то с этим нужно сделать, в противном случае получается, что Вика предоставляет ложную информацию.

Чебур 23:21, 11 августа 2012 (UTC)[ответить]

А что не так написано? Тут действительно "контроллер выступает в роли класса с единственным методом run()". У данного контроллера НЕТ других публичных методов, его public API - это run(), который вызывается из контроллера приложения. Конечно же у контроллера-родителя есть другие методы, но это банальное наследование, которое описывать тут смысла не имеет. Умный поймет, глупый пусть читает про азы ООП. — Эта реплика добавлена участником Василий Берестов (ов) 07:59, 16 августа 2012 (UTC)[ответить]

Фраза "...через метод контроллера checkAccess() проверяется, имеет ли пользователь доступ к этой странице..." не вяжется с фразой "...Контроллер не содержит в себе какой-либо бизнес-логики...". Так все таки контроллер должен содержать бизнес-логику проверки прав пользователя или нет? Если нет, то где она должна быть реализована? 90.157.59.157 18:27, 6 декабря 2012 (UTC)[ответить]

проверка прав пользователя не относится к бизнес-логике, которая есть суть описание механизмов взаимодействия с данными, то есть описание объектов данных, методов их модификации и интерфейса чтения/записи данных в хранилище. это и относится к бизнес-логике. проверка прав пользователя - это механизм аутентификации/авторизации пользователя, и он должен работать задолго до того, как контроллер начинает взаимодействовать с бизнес-логикой, то есть с данными. Paоla Celeste (обс.) 09:22, 31 июля 2019 (UTC)[ответить]

Изменение примера, т.к. он просто отвратительный[править код]

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

Пример контроллера MVC в рамках PHP5[править код]

<?php
/* 
 * Реализация MVC в рамках шаблона Active Record
 */
class User extends ActiveRecord {
   protected $password;
   
   public function getPassword() 
   {
      return $this->password;
   }

   public function checkUserPass($pass)
   {
      return $this->getPassword() === $pass;
   }  

   public static function findByLogin($dbProvider, $login) {
      return parent::findByLogin($dbProvider, $login);
   }
}

class MyController extends Controller
{
  protected $dbProvider;

  public function action($login, $pass) {
     $user = User::findByLogin($this->dbProvider, $login);
     $result = $user->checkUserPass($pass);

     if ($result) {
         return $this->getView()->load('user/profile', array('user'=>$user));
     }
     
     return $this->getView()->load('login', array('lastLogin'=>$login));
  }
}

/*
 * Реализация MVC в рамках шаблона Data Mapping
 */
class User {
   protected $password;
   
   public function getPassword() 
   {
      return $this->password;
   }
}

class UserService {
   public function checkUserPass(User $user, $pass)
   {
      return $user->getPassword() == $pass;
   }  
}

class MyController extends Controller
{
  protected $dataMapper;

  public function action($login, $pass) {
     $user = $this->dataMapper->getUser($login);
     $bissnessLogic = new UserService();
     $result = $bissnessLogic->checkUserPass($user, $pass);
     
     if ($result) {
         return $this->getView()->load('user/profile', array('user'=>$user));
     }
     
     return $this->getView()->load('login', array('lastLogin'=>$login));
  }
}
85.26.168.122 12:39, 10 сентября 2012 (UTC) SowingSadness on habrahabr.ru[ответить]

Концепция у MVC, но MVC не концепция и не схема.[править код]

„С развитием объектно-ориентированного программирования и понятия о шаблонах проектирования был создан ряд модификаций концепции MVC, которые при реализации у разных авторов могут отличаться от оригинальной. Так, например, Эриан Верми в 2004 году описал пример обобщенного MVC[4]“

MVC не концепция и не схема. MVC — парадигма (A Description of the Model-View-Controller User Interface Paradigm in the Smalltalk-80 System). Но у парадигмы MVC есть концепция, так же MVC может быть концепцией в framevork'e. Так вот во всем разделе «Канцепция» термин употребляется верно, но в данном предложении идет о различной реализации парадигмы MVC, а никак не концепции. Да и сноска ведет никак не на страницу с изменением концепции, а не конкретную реализацию. В любом случае, нельзя не признать, что MVC является шаблоном проектирования. Возможно такая ситуация возникла из-за не точности в определении одного из терминов. А возможно такой дуализм действительно присутствует. -- 85.26.168.122 08:35, 11 сентября 2012 (UTC) [SowingSadness on habrahabr.ru][ответить]

Описание пассивной модели MVC[править код]

В статье указывается, что при пассивной модели MVC бизнес-логика находится в Контроллере, а в Модели только данные. Это совершенно не так. Если рассматривать область web приложений, то характерными примерами пассивной модели MVC являются JSP в J2EE и ASP.Net. Хотя ASP.Net, насколько я знаю, поддерживает и активную модель. При использовании JSP в простейшем случае это выглядит так. Есть View, он же JSP, который отвечает за отрисовку интерфейса. Есть Model, который состоит минимум из 2х слоев - Domain и Data Access - это, соответственно, классы с бизнес-логикой и классы для работы с хранилищем данных (СУБД, файлы и т.п.). Также есть Controller, он же сервлет, который 1) Получает запросы от клиентов 2) Создает необходимые объекты бизнес-логики. При необходимости заполняет объекты данными из запроса. Выполняет методы этих объектов для обработки данных в соответствии с бизнес-логикой. 3) Помещает объекты в ответ клиенту 4) Выбирает нужный View (jsp) и дает команду на перерисовку 5) View получает ссылку на объекты бизнес-логики и считывает из них данные для отрисовки.

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

2A00:1120:0:1100:0:0:144:36 14:40, 13 февраля 2014 (UTC)[ответить]

Категоричность утверждений в частых ошибках[править код]

Утверждение что "Но в объектно-ориентированном программировании используется активная модель MVC, где модель — это не только совокупность кода доступа к данным и СУБД, но и вся бизнес-логика." является всего лишь мнением. Причем в тексте нет ссылок на оригинальный работы отстаивающие такое мнение. В то-же время существуют иные мнения - в частности- о том что бизнес логика должна содеражаться в классе прослойке между контроллером и моделью. На мой взглад необходимо переделать эту часть в условном ключе- некоторые (ссылка) считают так а другии (ссылка) считают иначе. 2001:420:44B1:1300:A52B:E3FC:B063:F4E7 15:02, 9 июня 2015 (UTC) Кирилл[ответить]

Взаимоисключающие параграфы[править код]

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

"Функциональные возможности и расхождения

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