Обсуждение:Разделение визуализации и бизнес-логики

Модель - это данные, представление - это отображение данных. Да, представление зависит от модели. Например, когда отображается сложный объект: у него есть либо такой набор свойств, либо другой. А вывод, который вы делаете из этих слов уже сильно надуманный. Насчёт остального - я не дочитал, может быть позже. Но MVC - это не парадигма, а концепция. Набор правил, которых стоит придерживаться, чтобы облегчать жизнь с одной стороны верстальщикам или конструкторам GUI интерфейсов, с другой - разработчикам баз данных. Моё впечатление, что прослойки (в виде PHP, Python, ASP.Net и прочего) имеют всё меньшее и меньшее значение. Всем рулят данные и конкретная визуализация. --Dipsy 21:06, 30 июня 2011 (UTC)

MVC - это не парадигма, а концепция - разница ? --S.J. 21:53, 30 июня 2011 (UTC)

ответ см. в Википедии, либо в моём предыдущем посте. --Dipsy 14:29, 1 июля 2011 (UTC)

ну в википедии написано формально - шаблон проектирования, это слишком узкое определение. Слова "парадигма" и "концепция" слишком перегружены, и могут в зависимости от контекста обозначать разное. Так это MVC затрагивает весь программный код, то я склонен считать, что это парадигма, конечно не такая крупная как ООП, но тем не менее. Более того MVC - противоречит другой парадигме ООП. Конечно, можно определить и более точно, тогда MVC - это способ построения архитектуры программы. И нет, это не набор правил, это вполне четкая программная конструкция. --S.J. 14:49, 1 июля 2011 (UTC)

Википедия может описывать MVC как считает нужным, опираясь на авторитетные источники, я не это имел в виду. Да, можно считать, что MVC это способ построения архитектуры кода, тогда: (1) MVC может затрагивать весь код. (2)MVC может не приминяться совсем, (3)MVC может затрагивать часть кода. Если считать MVC чёткой конструкций, то все объекты программы должны быть оформлены одним способом независимо от их размера и выполняемых действий и мы приходим к варианту (1) или (2). Но как правило есть: 1) невизуальные объекты. 2) маленькие объекты, которые удобнее захардкодить на уровне представления. И в этом случае получается вариант (3): MVC затрагивает только часть кода. Какие объекты считать маленькими или большими - это усмотрение программиста. Получается, что чёткость констукции - вещь сильно субъективная. Я придерживаюсь той позиции, что всё хорошо в меру, потому мне ближе именно третий вариант. Часто для реализации разделения MVC в php используют шаблонизаторы, но на каком-то уровне развития в шаблонизаторе появляются операторы, переменные: возникает мета-язык. А потом люди в интернетах начинают жаловаться: "фи, какая гадость. так нельзя было писать, это уже не MVC". да, не MVC. ну и что? Всё очень сильно зависит от конкретной ситуации. Я согласен, что концепция MVC нужна, но жить бесприкословно по её принципам невозможно. Точно так же, как в ООП-программах появляются отдельные функции. А просто потому что вызов функции быстрее вызова метода. Да пусть он будет! Когда-то я был совсем наивным и всерьёз верил, что стандарт xhtml должен изменить мир. Я общался со взрослым программистом. Он сказал: я ничего не слышал про твои стандарты, хотя и работаю в этой области. Стандарт не может изменить мир. Всем нужен этот запутанный кривой код, потому что люди так привыкли писать и браузеры должны будут его поддерживать. Прошло много времени и появился изменяющийся стандарт html5, примерно с такими же аргументами. Потому что жизнь - не теория, жизнь - это практика. Надо искать компромиссы. --Dipsy 14:44, 3 июля 2011 (UTC)

Да, классический MVC не подарок, но при разработке архитектуры, нужно его чем то тогда заменить. Тут я и начал описывать чем и как. MVC декларирует важность разделения визуализации и бизнес-логики. Поэтому когда вы тут рассуждаете от том, что можно отказаться в каких-то случаях от MVC, то получается что вы говорите, что можно не выполнять принцип отделения визуализации от бизнес-логики. Т.к. мы тут решаем т.н. задачи в большом, грубо говоря когда программа пишется несколькими людьми и сопровождается несколько лет, и при этом пользователей у нее не менее 10, и все хотят со временем так или иначе доработать. То то, что было когда то маленьким, может легко стать большим, а то, что не имело визуализации когда-то ее приобретет. Всего этого заранее не знаешь, где "выстрелит" не угадаешь. Поэтому люди и создают архитектуру ПО (и не для чего более). И если мы не продумаем архитектуру, или будем поступать что называется на „усмотрение программиста“, то через 2-5 лет на работу приглашают таких как меня  :) И после этого у программиста нету "усмотрений" и он кодит все согласно разработанной и утвержденной системной архитектуре, созданной проектировщиком. Вот это жизнь и практика, и нет ни каких компромисов, иначе ПО не живет больше 5 лет. --S.J. 20:24, 3 июля 2011 (UTC)

Всё здорово, только домысливать за меня не надо. Да, ваш подход приводит к созданию больших и устойчивых программ. Я ж разве с этим спорю? Только те же программы бывают оказываются в результате очень медленными. Один из главных критериев для меня: программа должна работать быстро. Соблюдение всех-всех правил и соглашений - это как прохождение по всем бюрократическим инстанциям ради получения какой-нибудь бумажки. Исключения имеют право быть. Если программист не понимает где и в каком случае можно делать исключения, то да: ему дорога в аутсорс и к строгому соблюдению всяческих требований. А я не из их числа, извините уж. Только, предупреждая ваше желание дорисовать картинку, я не пропагандирую диссидентские взгляды, типа: "давайте будем плевать на архитектуру". Нет. Всего-навсего говорю, что и в рамках архитектуры есть свобода. И если у человека есть мозги, то он должен ими пользоваться. --Dipsy 21:08, 3 июля 2011 (UTC)

Ок, тогда ниже можем говорить конкретнее, про те случае когда соблюдаем некую архитектуру, а не делаем ОСОЗНАННО и ОБДУМАННО исключение. --S.J. 21:26, 3 июля 2011 (UTC)

визуализация создает (порождает) модель (бизнес-сущность)

О чем надуманный не ясно. Но начнем все по порядку, иначе будет каша. (тут высокие материи :) ) Желаете ? --S.J. 21:53, 30 июня 2011 (UTC)

представление зависит от модели означают то, что визуализация создает (порождает) модель (бизнес-сущность)

вот этот вывод мне кажется странным. да, представление зависит от модели. но дальше: визуализация создаёт бизнес-сущность - совсем нет.

Можете уточнить, как по вашему представление зависит от модели ? --S.J. 19:40, 3 июля 2011 (UTC)

В зависимости от данных может измениться внешний вид интерфейса. --Dipsy 20:45, 3 июля 2011 (UTC)

Да, представление зависит от модели. - И Вы хотите сказать, что это есть хорошо ? Если ограничится тем, что вы читали, то я утверждаю, что это УЖАСНО. Это выбрось и забудь все принципы программирвоания вообще. (это если в большом :) а так садись два ;) )--S.J. 21:55, 30 июня 2011 (UTC)

Так, давайте ограничимся тем, что будем обсуждать тему, а не то что я читал или не читал. Что знаю, то моё. А что не знаю, на то не претендую. Про то что есть хорошо или не есть хорошо - отвечу в общем смысле, что оценка - это не свойство объекта, а лишь суждение субъекта. --Dipsy 14:08, 3 июля 2011 (UTC)

Что касается будем обсуждать тему, а не то что я читал или не читал, я имел введу, сказанное вами же : Насчёт остального - я не дочитал, может быть позже. Поэтому обсуждать будем когда дочитаете - и скажите, дочитал, понял или вот такие есть вопросы ... --S.J. 15:06, 3 июля 2011 (UTC)

Я не продолжаю читать до конца статьи, лекции, учебники, прежде чем не переработаю ту информацию которую прочёл в них уже. Мне нравится называть это свойство фундаментальностью. Так получилось, что в текущей статье такие моменты стали появляться практически сразу, а не в завершении. Если я не пойму, что вы имели в виду в середине статьи, то скорее всего не дочитаю статью до конца никогда. --Dipsy 15:23, 3 июля 2011 (UTC)

Вот см. [1] раздел 3.3.2 Представление, ну это я надумал, что в BaseView есть ссылка на model ? Или это не типичная реализация в MVC ? --S.J. 22:19, 30 июня 2011 (UTC)

Контроллер передаёт представлению данные модели: или через ссылку на модель, или передав данные объекта. (а есть ещё варианты?) Но одно и то же представление может служить для добавления и для редактирования объекта. При добавлении объекта соответствующая ссылка будет null-ом. Варианты бывают разные. Но ссылка на модель из представления не та ссылка, которая обеспечивает существование объекта модели. --Dipsy 15:03, 3 июля 2011 (UTC)

визуализация как функция бизнес-сущности

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

При добавлении, визуализация объекта существует раньше самого объекта, поэтому не всегда визуализация - функция бизнес сущности. Когда создавать объект визуализаии - по идее должен решать контроллер, а не бизнес-сущность (модель). На практике же, можно обойтись и решением на уровне преставления: человек нажал на кнопку - у кнопки сработал обработчик: отобразился (а может быть и создался) визуальный объект. --Dipsy 15:12, 3 июля 2011 (UTC)

• Вот именно так и происходит на практике, т.е. кишь-мишь и сбоку бантик. Но зачем тогда говорить, что решается задача разделения визуализации и бизнес-логики? Ведь тут нет никакого разделения. Начнем с простого:

1. можно обойтись и решением на уровне преставления: человек нажал на кнопку - у кнопки сработал обработчик: отобразился (а может быть и создался) визуальный объект

Где же тут разделение, если все происходит в одном визуальном классе (или его подклассах), какую бизнес-логику тут выделили ? Куда ? Правильно как она была в обработчике так и осталась. --S.J. 19:50, 3 июля 2011 (UTC)

Есть визуальный класс. Он отображает интерфейс. Этот интерфейс связан с контроллером. Контроллер может создать объект бизнес-логики. Объект бизнес-логики объект работает в системе без участия GUI. GUI не знают о том, создался ли объект, пока контроллер не сообщит результат. Когда отчёт о создании придёт - начнётся обработка: запустится логика отображения. Отделение в том, что отделена логика отображения от бизнес-логики. Объект существует в системе и не знает о том, что его могут изменить GUI. Он, может быть, только знает о том что он в-принципе может измениться. А может, и не знает. --Dipsy 20:24, 3 июля 2011 (UTC)

Ок, вы тут уже описали собственно MVC, но выше речь шла о решении на уровне преставления (или я вас не понял), т.е. когда нет контроллера, и возможно модели. А есть только визуализация, у которой вся бизнес-логика написана в обработчике, нажатия на кнопку. Ниже попробую создать примерчик, чтобы мы понимали бы друг друга одинаково. --S.J. 20:56, 3 июля 2011 (UTC)

Не-не-не. Пример был не про это. Имелось в виду: есть два интерфейса. Один интерфейс по клику мыши открывает второй с заданными параметрами. Да, контроллер не участвует, но из этого однозначно не следует, что он не существует совсем. Хотя в-принципе, может и не существовать: например, если интерфейс изменяет стили шрифтов или какие-то другие свойства. Если нет потребности в модели и в контроллере, то не надо их создавать только для того, чтобы всё было в архитектуре MVC. Есть золотое правило: не плоди сущности без надобности. Есть ещё одно замечательное: разделение ради разделения не нужно. --Dipsy 20:47, 4 июля 2011 (UTC)

Вы, тут снова начинаете "запутывать". Мы или говорим об исключениях, когда не используем архитектуру MVC или говорим о том как использовать эту архитектуру MVC. Об исключениях давайте говорить позже (как и договорились разделом выше). А ниже на примере хотелось бы понять как вы используете архитектуру MVC, когда есть все 3 его части. Так будет проще объяснить суть собственно обсуждаемой статьи. Там я жду ваших переделок ... --S.J. 22:21, 4 июля 2011 (UTC)

Здесь дело не в исключениях: просто вы взяли мою фразу и начали строить по ней рассуждения. Попробую добавить ещё ясности: я считаю, писать программу целиком на чистом MVC неразумно. MVC хорош для расширения функционала: писать модули или плагины, которые должны органично вписываться в разрабатываемую систему, или чтобы можно было привлечь сторонних разработчиков. --Dipsy 17:30, 5 июля 2011 (UTC)

Ну, тогда мне придется повторить, что я говорил в самом начале: можно не выполнять принцип отделения визуализации от бизнес-логики ? Да или нет ? --S.J. 20:03, 5 июля 2011 (UTC)

2. При добавлении, визуализация объекта существует раньше самого объекта

Существует визуализация раньше бизнес-объекта или нет решает исключительно программист. От этого решения и будет зависеть архитектура. Плоха та архитектура, когда это происходит случайно, в зависимости от каких-то несущественных условий, почти как захотелось сделал так в одном случае, а в другом по другому. Когда же архитектура продумывается могут быть только два варианта: (1) всегда существует вначале визуализация (2) всегда существует вначале бизнес-объект. Так как не каждый бизнес-объект обладает визуализацией, то предпочтительнее архитектура №2. Она и логичнее, не может существовать визуализация чего-то, пока нету самой сущности. Иначе у нас снова появляются кишь-мишь логика, т.е. для объектов без визуализации вы будите создавать их, а для объектов с визуализацией вы будите создавать представление (визуализацию). Теперь если вдруг, через год, вам нужно будет некий объект ранее не имевший визуализацию, снабдить визуализацией, то тут и закончится ваша архитектура. Придется перестраивать все ранее созданные связи. --S.J. 20:01, 3 июля 2011 (UTC)

3. Когда создавать объект визуализаии - по идее должен решать контроллер, а не бизнес-сущность (модель).

Это уже третий вариант архитектуры (когда всегда вначале существует контроллер). Можем обсудить и его. Он существенно лучше, но есть проблемка. Кто будет создавать сам контроллер ? В какой момент ? --S.J. 20:07, 3 июля 2011 (UTC)

Контроллер может создаваться при инициализации приложения и далее разруливать логику. Только не всегда получится создать активный контроллер, если приложение рассчитано на взаимодействие с пользователем. При инициализации создаются какие-то начальные GUI, но не обязательно это будут сразу же представления каких-то объектов. Я вам ещё одну жуткую вещь скажу: MVC может быть вложенным. --Dipsy 20:32, 3 июля 2011 (UTC)

И сколько контроллеров вы создадите сразу при инициализации ? 1001 объект на каждую возможную визуализацию (форму) ? Кто создаст объекты визуализации ? Визуализация будет создана раньше контроллеров или нет ? --S.J. 20:45, 3 июля 2011 (UTC)

Не, зачем 1001? я создам 100500 объектов.
Ну, об чём речь?? От того, что я пишу "может", не следует "должен создаваться". А вы уже, кажется, хотите привести меня в этом к противоречию. В общем случае задачи не решаются. Есть серверные приложения с небольшим web-интерфейсом. Есть базы данных с "богатым" клиентом. Есть десктопные приложения. Может быть есть только консольный интерфейс. Конкретнее, пожалуйста. И, кстати, я не возьмусь обещать, что я сходу предложу правильное решение или, может, вообще не предложу решения. --Dipsy 21:23, 3 июля 2011 (UTC)

Ну, давайте для офисного оконного-приложения. --S.J. 21:34, 3 июля 2011 (UTC)

Я бы сделал или один объект, или два объекта (в зависимости от сложности и размера приложения). Но это не совсем контроллер, скорее "мета-контроллер". Его функции: создание необходимых сущностей в оперативке (простых моделей, скорее всего, без ссылок и вложенностей, но реестра может и не быть вовсе) и, позднее, управление ими (управление реестром объектов). Если объектов всё-таки два, то второй можно было бы назвать "мета-моделью". Следующим шагом этот мета-контроллер создаётся объект, отрисовывающий интерфейс (типа "мета-представление"). --Dipsy 20:28, 4 июля 2011 (UTC)

Простейший пример реализации MVC

class View
{
   Controller myController;

   TextBox Name;
   TextBox Address;

   ChangeName(string newValue)
   {
      myController.ChangeName(newValue);
   }
   ChangeAddress(string newValue)
   {
      myController.ChangeAddress(newValue);
   }
}

class Model
{
   string Name;
   string Address;

   FindNameByAddress(string argAddress)
   {
       // ищем имя
       Name = newValue;
   }
   FindAddressByName(string argName)
   {
       // ищем адрес
       Address = newValue;
   }
}

class Controller
{
   Model myModel;
   View myView;

   Show()
   {
      myModel = new Model();
      myView = new View();
      myView.myController = this;
      myView.Show();
   }

   ChangeName(string newValue)
   {
      myModel.Name = newValue;
      myModel.FindAddressByName(newValue)
      myView.Address = myModel.Address;
   }
   ChangeAddress(string newValue)
   {
      myModel.Address = newValue;
      myModel.FindNameByAddress(newValue)
      myView.Name = myModel.Name;
   }

}

main
{
   Controller myController = new Controller();
   myController.Show();
}

Правильно я понимаю, что примерно это вы описали разделом выше в пункте №1. --S.J. 21:07, 3 июля 2011 (UTC)

Да, похоже на правду. Но не совсем: 1) контроллер не должен иметь доступа к контролам представления. 2) у вас немного запутано - find и change. --Dipsy 21:39, 3 июля 2011 (UTC)

Перепишите ниже тогда, как было бы правильно. По поводу find и change - идея такая, что по вводу имени, нужно найти и заполнить адрес, и наоборот. Это тоже момент для переписывания, но придерживаясь концепции MVC, я не знаю как было бы правильнее - поменяйте. Тогда и обсудим недостатки, сейчас они есть, но исправить их в модели MVC думаю нельзя. --S.J. 21:46, 3 июля 2011 (UTC)