LINUX.ORG.RU

MVC — до какой степени разделение Model и View кошерно?


0

0

На днях поспорил с коллегой насчет концепции MVC.

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

Коллега же — сторонник идеи о loose coupling, что заключается для него в том, что View вообще должен получать независимый от источника набор структурированных данных, желательно в XML, которые форматировать по разумению. Подготавливать эти данные должна либо модель, либо контроллер.

Я не согласен с этим подходом потому, что, по моему мнению, 1) ни контроллер, ни модель не должны делать не свою работу (тот XML — это тоже view как-бы), 2) это усложняет разработку, вместо всяко ее упрощать, в коде появляется много лишних букв и поводов совершить ошибку, 3) XML — формат обмена между вообще независимыми черными ящиками, и пользовать его внутренне в рамках одной программы — оверкилл.

Коллега не согласен с моим подходом, так как полагает, что доступ слоя View к объектам модели некошерен по сути и нарушает сам принцип разделения.

Кто же из нас неправ, all?

★★★★★

> Кто же из нас неправ, all?

Коротко. Он.

Dendy ★★★★★
()

ООП зохавало моск

imp ★★
()
Ответ на: комментарий от dilmah

Ну расскажи мне про юникс-вей в рамках одной программы.

shimon ★★★★★
() автор топика

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

Laz ★★★★★
()
Ответ на: комментарий от anonymous

Нихера он не прав. Любое архитектурное решение должно прежде всего облегчать жизнь.

temp
()

Полное разделение V и C (ты их имел в виду, а не M и V?) возможно только на примитивных задачах. Ибо в сложных проектах разделить их принципиально невозможно. Или вид проникает в код контроллера, или код - в вид.

Грубо: или мы if(vip) { out = "<b>".out."</b>"; } засовываем в контроллер, или {if $obj.vip}<b>{$out}</b>{/if}... в вид.

Второе - в общем случае более кошерно.

Общий вывод - логика вывода, даже если это контроллер должна быть в виде, а вот логика модели - в коде контрллера.

...

Хотя в частных случаях - возможны разные детали...

KRoN73 ★★★★★
()
Ответ на: комментарий от dilmah

> Он отстаивает юникс-вей.

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

Dendy ★★★★★
()

Должен быть набор BOM (Business Object Model) объектов, которыми должны уметь оперировать все составные части MVC. Т.е. Model должен уметь получать/сохранять эти объекты, Controler - производить операции с ними, а View - отображать.

xml - это вообще уровень интеграции с внешними системами.

> Коллега не согласен с моим подходом, так как полагает, что доступ слоя View к объектам модели некошерен по сути и нарушает сам принцип разделения.

imho - коллега не полностью понимает суть MVC

Crocodille
()
Ответ на: комментарий от Crocodille

> Должен быть набор BOM (Business Object Model) объектов, которыми должны уметь оперировать все составные части MVC. Т.е. Model должен уметь получать/сохранять эти объекты, Controler - производить операции с ними, а View - отображать.

То есть: если рассматривать классические ORM (например, Propel или Doctrine в PHP), то можно обозвать их entity objects (соответствующие рельсовским ActiveRecords) такими BOM и не морочить себе голову, принадлежат ли они модели, контроллеру или виду (потому что они принадлежат всем), то это будет счастье, я верно понял?

Одна поправка: мне кажется, чистый MVC предполагает, что контроллер сам по себе не может производить операции с BOM. Он может в соответствии с полученными событиями сформировать BOM (или набор BOM), сообщение с просьбой что-то там сделать и пнуть этим всем модель. Точно то же самое он делает с видом, но сам по себе модифицировать данные он не должен.

shimon ★★★★★
() автор топика

а по-моему все вы неправы и страдаете фигнёй; умный дядька Влиссидес после выхода GoF неоднократно пытался донести до людей простую истину, которую они где-то походу прое~wпотеряли: паттерн не является универсальным решением обобщённой задачи - он вообще не является решением. никакой задачи. даже такой хороший паттерн как MVC

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

jtootf ★★★★★
()
Ответ на: комментарий от Dendy

> Dendy * (*) (23.12.2008 16:56:09)

напиши на adrumus загуглина gmail.com, есть вопрос.

q
()
Ответ на: комментарий от shimon

Они не принадлежат никому, наоборот, Model, View и Controller зависят от бизнес-объектов.

> Одна поправка: мне кажется, чистый MVC предполагает, что контроллер сам по себе не может производить операции с BOM

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

вот ссылка, тут всё по умному расписано: http://rsdn.ru/article/patterns/generic-mvc.xml

Crocodille
()
Ответ на: комментарий от Crocodille

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

shimon ★★★★★
() автор топика
Ответ на: комментарий от Crocodille

А, да, вдобавок ведь — контроллеров может быть несколько. Командная строка — раз; веб — два; специальный гуй интерактивный — три; миддлеваре с подобием SOAP и прочий RPC — четыре; датчики в производственном цеху (например, камера в комнате для производства порнухи) — пять, тестовый контроллер для генерации ненастоящих событий — шесть. Это навскидку.

Если все вычисления повторять в каждом... А вот специфику работы с событиями определить в каждом — это уже поважнее.

shimon ★★★★★
() автор топика
Ответ на: комментарий от shimon

> А, да, вдобавок ведь — контроллеров может быть несколько. Командная строка — раз; веб — два; специальный гуй интерактивный — три; миддлеваре с подобием SOAP и прочий RPC — четыре; датчики в производственном цеху (например, камера в комнате для производства порнухи) — пять, тестовый контроллер для генерации ненастоящих событий — шесть.

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

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

Ian ★★
()
Ответ на: комментарий от Ian

По сути контроллер - это тот кто знает что надо сделать с моделью для того, что бы выполнить Use Case. То есть он по сути есть описание последовательности действий. Зачем это дублировать? Логика работы с моделью не меняется от изменения формы Представления.

Ian ★★
()
Ответ на: комментарий от shimon

imho командная строка, веб, гуй, SOAP/RPC - это больше view, т.к. подразумевают взаимодействие с пользователем (удалённым клиентом для RPC)

Датчики и камера - скорее внешние системы, которые надо опрашивать, т.к. сами они внятных запросов сформировать не могут, (т.е. некая read-only модель)

А вот саму логику (если при нажатии кнопки "А" (команде консоли "makeA") снимки на первой и второй камере похожи, тогда звоним в бубен) - определяем в контроллере. Она будет едина для всех view

Crocodille
()

Imho возможно сделать нечто среднее: объекты модели имеют в себе перечислители своих свойств, View пробегает по объектам и через фиксированный интерфейс достает свойства(например по именам). Тем самым не будет ни оверхеда на сериализацию ни лишнего в View. Хотя конечно если данные сильно сложные этот вариант imho не особо применим.

YesSSS ★★★
()

>желательно в XML

Предлагаю тех кто использует xml приносить в жертву JSONу.

wfrr ★★☆
()
Ответ на: комментарий от Crocodille

> imho командная строка, веб, гуй, SOAP/RPC - это больше view, т.к. подразумевают взаимодействие с пользователем (удалённым клиентом для RPC)

Обожди, экран, документ и веб-страница — это вывод.

А всякие клики, жмяки, команды — это никакой ни разу не view, это же ж ввод.

shimon ★★★★★
() автор топика
Ответ на: комментарий от Crocodille

> Датчики и камера - скорее внешние системы, которые надо опрашивать, т.к. сами они внятных запросов сформировать не могут, (т.е. некая read-only модель)

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

Захват событий и формирование сообщений «что делать» — это как раз контроллер.

Но view, это ж только результат, но не запрос. Вот тот же веб-запрос через GET или POST, это разве view?

shimon ★★★★★
() автор топика
Ответ на: комментарий от shimon

> Вот тот же веб-запрос через GET или POST, это разве view?

Да. View - это не только табличка с результатом, но и кнопочки. И тип интерфейса (веб или гуй) не должен заботить никого кроме View, Если слать POST/GET непосредственно контроллеру, то он должен будет вычитывать параметры запроса из http риквеста, что не есть Ъ, т.к. для другого типа View будет нужен другой контроллер.

Crocodille
()
Ответ на: комментарий от Crocodille

> т.к. для другого типа View будет нужен другой контроллер.

А оно же ж, имхо, так и есть. Полной изоляции быть не может.

shimon ★★★★★
() автор топика
Ответ на: комментарий от shimon

> А оно же ж, имхо, так и есть. Полной изоляции быть не может.

Если делать кошерно (enterprise level application, ага), то может.

Crocodille
()

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

кстати повторное использование кода и руление MVC - сейчас уже неактально:( Срок эксплатации более-менее серъёзной программы превышает время популярности языка/платформы/средства/clue раза эдак в два и вряд-ли хоть один компонент который вы делаете сейчас будет востребован через три года (исключение - вы профессионально пишите на FORTRAN). В лучшем случае это будет полная переработка на новых средствах.

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

>прав будет только начальник когда стукнет кулаком и заорёт "работать сукины дети !!"..и с этого момента всё ООП, слои и MVC пойдут нахрен - пользователь должен получить этот продукт, вот в этом вот виде, вот в такое вот время..

Наоборот. И ООП, и MVC, и модульность - всё это только в такой ситуации и спасает. Я, вон, просто на свои проекты глядя прекрасно помню, как то, что сейчас за пол-часа делается, раньше, без фреймворка, делалось за пару дней. Кроме того, если требуется вносить серьёзное изменение, то сейчас это минуты. А раньше - часы.

>кстати повторное использование кода и руление MVC - сейчас уже неактально :(

Значит не умеешь их готовить :D У меня, опять же, MVC-фреймворк (его ядром) без изменений используется на 5..6 сторонних проектах. Не считая основной работы и своего сайта :)

>Срок эксплатации более-менее серъёзной программы превышает время популярности языка/платформы/средства/clue раза эдак в два

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

>и вряд-ли хоть один компонент который вы делаете сейчас будет востребован через три года

У меня таких немало :)

> В лучшем случае это будет полная переработка на новых средствах.

Вам где-то крайне не повезло с первым опытом :)

KRoN73 ★★★★★
()
Ответ на: комментарий от MKuznetsov

> ..и с этого момента всё ООП, слои и MVC пойдут нахрен

ага, как известно, ооп, рекурсии, структуры - годятся только на смех курам

Crocodille
()
Ответ на: комментарий от MKuznetsov

> прав будет только начальник когда стукнет кулаком и заорёт "работать сукины дети !!"..и с этого момента всё ООП, слои и MVC пойдут нахрен - пользователь должен получить этот продукт, вот в этом вот виде, вот в такое вот время..

Ты не поверишь, но можно работать не на мудаков.

> кстати повторное использование кода и руление MVC - сейчас уже неактально:(


Бугога.

Срок жизни средней неигрушечной (когда заказчик ее использует, а не для галочки, и от этого зависит его бизнес) программы составляет в районе 7 (семи) лет.

shimon ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.