Вот Вам ещё одна «неудачная» ссылка en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller, там опять же в первой же строке пишется о том, что это паттерн разделения слоёв.
Боже ш ты мой, зачем вы все выдергиваете из контекста? Могли бы вообще из определения первое слово лишь оставить. Давайте насладимся полным описанием:
Model–View–Controller (MVC) is a computer software design pattern that separates the representation of information from the user's interaction with it.[1][2] The model consists of application data and business rules, and the controller mediates input, converting it to commands for the model or view.[3]
A view can be any output representation of data, such as a chart or a diagram. Multiple views of the same data are possible, such as a pie chart for management and a tabular view for accountants. The central idea behind MVC is code reusability and separation of concerns. [4]
Всё ваше не понимание текста, потому что вы не желаете понимать смысл терминов.
Если что-то действительно вам есть сказать по существу, без вырывания слов из контекста, то прошу. Если же нет, то надеюсь вы признаетесь самому себе, что кое что в этом мире вы понимали не так и ваши junior's вместе с вами начнут открывать прекрасный мир программирования по новому.
а не в сотый раз объяснять, что идея MVC это понятие недетерминированное,
Это для вас оно не детерминированное, потому что вы не понимаете что такое MVC.
Даже ссылаясь на Фулера, вы подтвердили это. Т.к. он пишет лишь о том, что в MVC удачная идея «Separated Presentation», но не более того!
Вы же умудряетесь говоря про «Separated Presentation» утверждать, что это и есть MVC.
Вы возможно хороший программист и прекрасно понимаете(чувствуете) как нужно разделить приложение на раздельные представления, но сам термин MVC вам не понятен.
P.S.
Мне очень хочется добиться, что бы люди перестали называть все что не поподя MVC подходом, лишь потому что им так стрельнуло в голову. Что бы не приписывали к «своему» выдуманному подходы минусы MVC используя некоторые его подходы при разработке.
Вы сослались на Фаулера и выделели цитату, которая ровным счетем ничего не говорит, кроме того, что в MVC главное идея, зовущаяся «Separated Presentation»
Давайте подискутируем по поводу моего описания MVC, с чем вы не согласны?
На счет ГОСТов. Если бы их не было, то рушились бы сооружения. ГОСТ не ограничивает гибкость, он задает правила стандарты, при проектировании.
Тоже самое и MVC.
Что значит загоняться по формулировкам.
Термины четко отражают скрытое в них значение.
Пример не смотрел, лишь определениями и меня они частично удовлетворили.
Суть в том, что бы правильно понимать то что вы используете.
Если делать так, как больше нравится, то и называть это надо правильно. Не MVC, а НСГ(«нам стрельнуло в голову»).
Уже сколько наблюдаю на хабре техническую безграмотность в применении терминологии, которая в свою очередь перерастает в не понимании технологии в принципе. Т.к. если человек не понимает, того что он читает, то как он сможет освоить и применить это корректно?
Не смотря на то что MVC разрабатывался не к веб, он все равно подходит. Только вот понимать его нужно правильно(читать научиться терминологию). Согласен, что в веб-разработке он не достаточно детально описывает подходы, но он не позволяет делать то, что творят горе-разработчика, а именно пихать бизнес-логику в контроллеры или в представление.
Если грубо, то MVC разделяет разработку продукта а следующие слои:
Model — описание бизнес-логики
View — отображение данных
Controller — валидация введенных данных и выбор отображения
Все четко и понятно, не надо изврещений типа:
Не надо загоняться по точным формулировкам, нужно всё делать удобно.
Программирование и так формализовано из рук вон плохо, все делается по наитию. Не надо привносить ещё больший хаос, стремиться нужно к пониманию технологии и развитию.
Где бы сейчас было строительство если бы не было ГОСТов?
P.S.
Соглашусь, пример отвратный в Wiki. Наверное я его перепишу и отправлю на подтверждение.
Модель (англ. Model). Модель предоставляет знания: данные и методы работы с этими данными, реагирует на запросы, изменяя своё состояние. Не содержит информации, как эти знания можно визуализировать.
Модель — это в первую очередь описание бизнес-процесса (Модель бизнес-логики)
А вот способ хранения данных и проецирование их в объекты относятся к другой задаче.
К задаче декомпозирования Model.
Есть два подхода(которые знаю я):
— Active Record
— Data Mapping.
Более развернуты ответ можете прочитать в комментариях в указанном вами топике.
/*
* AR
* Важный момент в AR то, что вы получаете экземпляр, прежде чем с ним работать.
* Прямые запросы в статике - как раз и есть тот плохой подход, который вы ругаете
*/
class User {
public function getPassword() { ... }
public static function findUserByLogin($dbProvider, $login) { ... }
public function checkUserPass($pass)
{
return $this->getPassword() === $pass;
}
}
class Controller
{
protected $dbProvider;
public function action($login, $pass) {
$user = User::findUserByLogin($this->dbProvider, $login);
$result = $user->checkUserPass($pass);
...
}
}
/*
* DM
*/
class DtUser {
public function getPassword() { ... }
}
class UserService {
public function checkUserPass(DtUser $user, $pass)
{
return $user->getPassword() == $pass;
}
}
class Controller
{
protected $dbProvider;
public function action($login, $pass) {
$user = $this->dbProvider->getDtUser($login);
$bissnessLogic = new UserService();
$result = $bissnessLogic->checkUserPass($user, $pass);
...
}
}
Прелесть камеры в Nokia Lumia 920 в том, что ты идешь и тебе срочно нужно что-то сфотографировать. И ты можешь это сделать.
Не смотря, день это или ночь. В пешей прогулке ты или на велосипеде.
Достал и сфоткал, как это обычно и бывает.
С остальными же аппаратами ты должен остановиться, зафиксировать руки, поменять режим и т.д.
А момент упущен, кадра нет.
А для контроллера больше ничего и не нужно. Ну вот зачем ему знать, какие операции можно проводить с данными? Ему только нужно знать, что вообще он может делать с моделью.
Это нужно не контроллеру, а разработчику.
Банально в контроллере я смогу сделать подобное не читая тонны документации:
public function action()
{
$specificUser = User::<все подскажет autocomplete IDE>;
}
Нет знаю, данные можно считывать, записывать и хранить. Подсистема бизнес-логики использует интерфейс высокого уровня подсистемы логики работы с данными, и может описывать свою логику не опираясь на хранилище.
Как бы в данном случае AR и DM идентичны, т.к. используют для работы с данными getters и setters.
class User {
protected $name;
public function getName() {
return $this->name;
}
public function setName($value) {
$this->name = $value;
}
}
Различая будут в реализации доступа к бизнес-модели:
/* DM */
$builder = new UserBuilder();
$user $builder->buildNewUser();
/* AR */
$user = User::buildNewUser();
Я не понимаю как вы в Data Mapping(DM) уйдете от проблемы изменения логики, при изменении структуры данных?
К тому же, появляется новая проблема, вы не знаете что можно делать с данными.
Т.е. вы инкапсулируете логику но не публикуете интерфейсы.
Поэтому я все же в вебе склоняюсь к Active Record(AR), т.к. при смене члена команды, ему не придется читать руководство разработчика по работе с данными и запоминать. У него есть интерфейс. Да и писать это самое руководство не придется.
К тому же, я руководствуюсь все время правилом: «Лучшая документация — это код». А в DM оно не соблюдается.
Хотя у DM есть одна интересная особенность. Если вам интересны данные в каком либо разрезе(например конкретный момент времени в прошлом), то у него тут большое преимущество перед Моделями в AR. Т.к. вы все время работаете со срезом данных и бизнес-логика к этому готова.
А в AR придется критерий среза передавать все время в методы.
Почему то, многие воспринимают Model лишь как проекцию данных из хранилища на объекты.
Model — это классы, которые реализуют логику работы над данными.
Как вы храните данные Model не интересует.
Способы реализации Model я знаю двух типов, с помощью:
— Active Record
— Data Mapping
В первом случае, данные хранятся вместе с бизнесс-логикой и публичные методы Model отвечают на вопрос «Что можно сделать с данным типом данных?
Во втором, данные отображаются в отдельные классы от реализации работы с данными. Реализация бизнес-логики находится в отдельных классах (например в сервисах по идеологии Symfony 2)
Тут я вижу одну проблему, решение которой, я пока не вижу.
Не понятно, что есть в бизнес-логике, для работы с данными.
Если с ActiveRecrod, все действия доступны как публичный интерфейс, то во втором, просто на уровне знаний или документации. А т.к. лучшей документацией должен быть код (интерфейс), то я попал в тупик %)
«Я ему про Фому, он мне про Ерёму»
Извините, но вы вообще не понимаете, и без того скудную, теорию по программированию. До тех пор, пока вы этого не поймете что термин это не пустое содрогание воздуха, для вас пустым звуком останутся такие понятия как:
— шаблон
— принцип
— способ
— модель
— система
— уровень абстракции и т.д.
И соответственно не придет понимание работы MVC, MVP и прочих шаблонов.
И тут не зависит все от решаемой задачи, т.к. весь принцип MVC описан в определении.
То что вы пытаетесь подсунуть под видом MVC им уже не является.
Это тоже самое, что заявить, указав на синие стены, что они красные. И что все зависит от того, в каком настроении вы на них посмотрите.
Там же написано:
> Контроллер — Обеспечивает связь между пользователем и системой: контролирует ввод данных пользователем и использует модель и представление для реализации необходимой реакции.
Контроль данных и выбор необходимого представления.
Боже ш ты мой, зачем вы все выдергиваете из контекста? Могли бы вообще из определения первое слово лишь оставить. Давайте насладимся полным описанием:
Всё ваше не понимание текста, потому что вы не желаете понимать смысл терминов.
Прежде чем писать дальше, про ознакомьтесь с документом, где чётко описана парадигма:
www.itu.dk/courses/VOP/E2005/VOP2005E/8_mvc_krasner_and_pope.pdf
Если что-то действительно вам есть сказать по существу, без вырывания слов из контекста, то прошу. Если же нет, то надеюсь вы признаетесь самому себе, что кое что в этом мире вы понимали не так и ваши junior's вместе с вами начнут открывать прекрасный мир программирования по новому.
Это для вас оно не детерминированное, потому что вы не понимаете что такое MVC.
Даже ссылаясь на Фулера, вы подтвердили это. Т.к. он пишет лишь о том, что в MVC удачная идея «Separated Presentation», но не более того!
Вы же умудряетесь говоря про «Separated Presentation» утверждать, что это и есть MVC.
Вы возможно хороший программист и прекрасно понимаете(чувствуете) как нужно разделить приложение на раздельные представления, но сам термин MVC вам не понятен.
P.S.
Мне очень хочется добиться, что бы люди перестали называть все что не поподя MVC подходом, лишь потому что им так стрельнуло в голову. Что бы не приписывали к «своему» выдуманному подходы минусы MVC используя некоторые его подходы при разработке.
Давайте подискутируем по поводу моего описания MVC, с чем вы не согласны?
На счет ГОСТов. Если бы их не было, то рушились бы сооружения. ГОСТ не ограничивает гибкость, он задает правила стандарты, при проектировании.
Тоже самое и MVC.
Термины четко отражают скрытое в них значение.
Пример не смотрел, лишь определениями и меня они частично удовлетворили.
Суть в том, что бы правильно понимать то что вы используете.
Если делать так, как больше нравится, то и называть это надо правильно. Не MVC, а НСГ(«нам стрельнуло в голову»).
Уже сколько наблюдаю на хабре техническую безграмотность в применении терминологии, которая в свою очередь перерастает в не понимании технологии в принципе. Т.к. если человек не понимает, того что он читает, то как он сможет освоить и применить это корректно?
Не смотря на то что MVC разрабатывался не к веб, он все равно подходит. Только вот понимать его нужно правильно(читать научиться терминологию). Согласен, что в веб-разработке он не достаточно детально описывает подходы, но он не позволяет делать то, что творят горе-разработчика, а именно пихать бизнес-логику в контроллеры или в представление.
Если грубо, то MVC разделяет разработку продукта а следующие слои:
Model — описание бизнес-логики
View — отображение данных
Controller — валидация введенных данных и выбор отображения
Все четко и понятно, не надо изврещений типа:
Программирование и так формализовано из рук вон плохо, все делается по наитию. Не надо привносить ещё больший хаос, стремиться нужно к пониманию технологии и развитию.
Где бы сейчас было строительство если бы не было ГОСТов?
P.S.
Соглашусь, пример отвратный в Wiki. Наверное я его перепишу и отправлю на подтверждение.
Каждый термин из аббревиатуры четко детерминирован.
ru.wikipedia.org/wiki/Model-View-Controller
ru.wikipedia.org/wiki/Model-View-Presenter
Вы не понимаете MVC.
Модель — это в первую очередь описание бизнес-процесса (Модель бизнес-логики)
А вот способ хранения данных и проецирование их в объекты относятся к другой задаче.
К задаче декомпозирования Model.
Есть два подхода(которые знаю я):
— Active Record
— Data Mapping.
Более развернуты ответ можете прочитать в комментариях в указанном вами топике.
Если расскажите, признаюсь что плохо понимаю преимущества данного подхода и извинюсь.
Как то так, вот 2 концепции.
Не смотря, день это или ночь. В пешей прогулке ты или на велосипеде.
Достал и сфоткал, как это обычно и бывает.
С остальными же аппаратами ты должен остановиться, зафиксировать руки, поменять режим и т.д.
А момент упущен, кадра нет.
Вот в чем прелесть… вот в чем фишка.
Это нужно не контроллеру, а разработчику.
Банально в контроллере я смогу сделать подобное не читая тонны документации:
В DM это сделать проблематично.
Как бы в данном случае AR и DM идентичны, т.к. используют для работы с данными getters и setters.
Различая будут в реализации доступа к бизнес-модели:
К тому же, появляется новая проблема, вы не знаете что можно делать с данными.
Т.е. вы инкапсулируете логику но не публикуете интерфейсы.
Поэтому я все же в вебе склоняюсь к Active Record(AR), т.к. при смене члена команды, ему не придется читать руководство разработчика по работе с данными и запоминать. У него есть интерфейс. Да и писать это самое руководство не придется.
К тому же, я руководствуюсь все время правилом: «Лучшая документация — это код». А в DM оно не соблюдается.
Хотя у DM есть одна интересная особенность. Если вам интересны данные в каком либо разрезе(например конкретный момент времени в прошлом), то у него тут большое преимущество перед Моделями в AR. Т.к. вы все время работаете со срезом данных и бизнес-логика к этому готова.
А в AR придется критерий среза передавать все время в методы.
Model — это классы, которые реализуют логику работы над данными.
Как вы храните данные Model не интересует.
Способы реализации Model я знаю двух типов, с помощью:
— Active Record
— Data Mapping
В первом случае, данные хранятся вместе с бизнесс-логикой и публичные методы Model отвечают на вопрос «Что можно сделать с данным типом данных?
Во втором, данные отображаются в отдельные классы от реализации работы с данными. Реализация бизнес-логики находится в отдельных классах (например в сервисах по идеологии Symfony 2)
Тут я вижу одну проблему, решение которой, я пока не вижу.
Не понятно, что есть в бизнес-логике, для работы с данными.
Если с ActiveRecrod, все действия доступны как публичный интерфейс, то во втором, просто на уровне знаний или документации. А т.к. лучшей документацией должен быть код (интерфейс), то я попал в тупик %)
Контроллер не реализует, он предоставляет выбор реализации. Т.е. он обращается к необходимой модели.
Если вы используете бизнес-логику в контроллерах — это уже не MVC.
Строго по определению.
Извините, но вы вообще не понимаете, и без того скудную, теорию по программированию. До тех пор, пока вы этого не поймете что термин это не пустое содрогание воздуха, для вас пустым звуком останутся такие понятия как:
— шаблон
— принцип
— способ
— модель
— система
— уровень абстракции и т.д.
И соответственно не придет понимание работы MVC, MVP и прочих шаблонов.
И тут не зависит все от решаемой задачи, т.к. весь принцип MVC описан в определении.
То что вы пытаетесь подсунуть под видом MVC им уже не является.
Это тоже самое, что заявить, указав на синие стены, что они красные. И что все зависит от того, в каком настроении вы на них посмотрите.
> Контроллер — Обеспечивает связь между пользователем и системой: контролирует ввод данных пользователем и использует модель и представление для реализации необходимой реакции.
Контроль данных и выбор необходимого представления.