Пожалуйста, добавляйте новые темы снизу


пересмотреть статью

править

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

  • 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 не имеет строгой реализации, то реализован он может быть по-разному. Нет общепринятого определения, где должна располагаться бизнес-логика."