"среди прочих диагнозов может быть" много чего. У меня мама год назад формально умерла от гриппа… А на самом деле от рака желудка и крайнего истощения. Врачи и так ей отводили несколько месяцев. И хотя формально ее убил грипп в прошлом году все понимали что это была смерть от рака. Дядя в этом году умер от того же самого — рак желудка и истощение (вес 48 кг у взрослого мужчины… рак желудка у нас семейное). Но теперь официально он умер от страшной болезни COVID и на фоне всеобщей истерии про рак никто и не вспоминает. Странно что людям так сложно понять что умереть от COVID и умереть от чего угодно при наличии COVID это две совершенно разные вещи. Особенно если учесть возможность того что бессистемно заражена может быть уже довольно большая часть населения. Если так рассуждать то скоро все смерти можно будет списывать на вирус. Кстати увеличение смертности может быть тупо просто следствием коллапса медицинской системы. Не знаю как в других странах, я в Испании, и тут можешь спокойно себе умирать дома от чего угодно. Если это не грипп врачи к тебе неизвестно когда приедут и не факт что приедут вообще (ко мне так никто и не приехал)
Смертность по европе от принятых мер вполне может расти. Я в Испании, медицина в коллапсе, госпитали закрыты и если ты умираешь дома не от Covid а от кишечной инфекции то к тебе просто не приедет врач или приедет через неделю когда ты уже умрешь. Вот статья про Израиль, там вроде бы коллапса нет, но людей настолько запугали и они так боятся подхватить вирус в приемном отделении больницы что сами не идут к врачу и в результате умирают дома… https://www.vesty.co.il/article/Sym11rhgu8
не буду ничего аргументировать… просто СПАСИБО! Как тесен мир, ваш пост прислали друзья… смотрю на ник и вижу Groks… единственный на кого у меня подписка в телеграмм. Удачи во всем
спасибо за «наводку» на пример «контроллер для «умного дома»»… Именна эта мысль меня и занимала последнее время — делать фасад как набор «команд». Интересно почитать как это реализовано у других. У меня тоже фасад довольно хорошо «разваливается» на независимые команды. Но чтобы понять почему у вас это не так… трех строчек что вы написали мало… нужно видеть весь ваш пример
Мне кажется вы задаете очень интересный вопрос, но нет уверенности что правильно вас понимаю, поэтому если «мимо» то извините. Мне кажется что фасад не должен давать клиенту ссылки на доменные объекты. Фасад всегда дает клиенту объекты-заглушки. Если есть возможность то это могут быть объекты-прокси, но иногда без копирования не обойтись (например как в вебе) и тогда данные например из доменного объекта Post, который обращается к базе данных и берет из нее данные будут копирваться в клиентский объект PostInfo (с точно такими же полями), который собственно и будет возвращен клиенту
Самое граммотное что удалось найти в инетете по работе со звуком. Спасибо от меня громадное и кармы впридачу. Целый день промучались… хорошо что вас нашли, а то бы еще завтра мучались
это да… меня тоже это останавливает. Угрузившись в «историю» начинаешь связи видеть, понимать откуда ноги у современности растут и вообще там многое нагляднее что-ли… и при этом «красиво». Но пока нет уверенности что это кому-то надо, а без этого… времени и так в обрез. Поэтому выкладывается только самое «выстраданое»
да! вы нашли самое начало… Только читается очень тяжело. Я во второй части ее довольно подробно разберу и постараюсь дать немного пояснений чтобы было легче читать. У меня тоже валяются переводы. Так что если у народа будет интерес то можно объединить усилия и выложить
про иерархический MVC действительно инетерсная тема… здорово что вы на нее вышли. Мы пока решили ее не затрагивать чтобы не перегружать.
По поводу Модели… Вы правы, если читать лишь описания то и у Барбека и у Краснера действительно написано что модель это доменный объект (любой объект Smalltalk) как вы верно и заметили. А вот на практике всегда был «фасад» между ними. И специальный объект Model от которого наследовались все модели был выделен особо, а это значит что опять таки на практике не любой объект Смоллтолк мог быть моделью. Это то и есть самое интересное. Предполаю что связано это с тем что тогда действительно не было шаблонов, они были «первопроходцами», поэтому практика опережала «теорию». Кстати у Реенскауга в описании фасад тоже появился позже…
А вот насчет бессмысленности разделения UI на вид и контроллер в отрыве от библиотеке… Тут с вами не соглашусь пока. Во второй части попробую показать что это штука довольно универсальная и существующая не только в программах а вообще почти в любом интерфейсе
Для наглядности. Если нет ограничения по ресурсам то сначала делаем стандартную реализацию (1) согласно идеологии DDD и не важно что тянутся лишние объекты.
Когда (и если) возникла необходимость в оптимизации можно перейти к чему-то подобному (2)
Поскольку интерфейс фасада в обоих случаях будет одинаков то на клиенте переход от 1 к 2 никак не отразится. Именно в этом и заключается смысл фасада — можно менять конкретную реализацию бизнесс модели а клиент этого даже не заметит
Понятно… Вы под тепрмином модель грубо говоря понимаете каждый «объект» в своем приложении. Нет конечно же в статье имелось ввиду что доменная модель это не каждый отдельный объект а именно «приложение» которое реализует некий функционал.
Грубый пример — поисковый робот который бегает по сети и индексирует где и что находится, чтобы, когда вы обратитесь к поисковику, вам информация была выдана быстро и удобно. Роботу, который в этом случае и будет приложением «все равно на отображение» но тем не менее его работа заключается именно в том чтобы сделать доступ к информации быстрой и удобной.
Мне кажется что в вашем случае (и вообще при работе с базами и не базами) все тоже самое только в предельно упрощенном виде — должно быть некое приложение или модуль в приложении (и этот модуль будет относится именно к доменной модели в терминологии MVC) который знает где находится информация и как ее оптимальным образом извлечь и в удобной форме вернуть для дальнейшего использования. Он может ее просто извлекать, или частично кэшировать для быстрого дальнейшего доступа… не суть важно, важно чтобы именно в доменной модели за эту задачу кто-то отвечал.
И если удобная форма это просто набор строк… То значит этот модуль не должен тащить объекты а должен с помощью SQL запроса извлечь из базы лишь нужные вам строки и вернуть (как и написал Volch). А уж что вы с этими строками будете делать дальше это уже ваше дело — можете отображать, можете для какой-нибудь аналитики или отчетов использовать.
да! Это ведь к сожалению весьма распостраненное мнение что Вид ни в коем случае не должен содержать логику. Опять таки у Фаулера на эту тему есть интересный пример… он показывает что иногда в результате «состояние и логика Вида» могут пробраться даже не в контроллер а в доменную модель
Если я правильно понимаю вашу задачу, то мне кажется что у фасада просто должен быть метод наподобе этого:
String[] getFIO();
клиент должен получить готовый список из 10 строк с Ф.И.О. людей…
А формироваться этот список должен внутри доменной модели, котороя знает как наиболее оптимальным образом вытащить эти данные из базы или еще откуда. В крайнем случае этот список может формировать фасад… но вообще это опасная дорожка по направлению к тому что фасад начнет реализовывать бизнесс-логику. Просто в вашем примере только база и фасад и мне пока не очень понятно где там находится бизнесс-логика
Простите, не очень понятен вопрос. Там прямо под картинкой цитата Фаулера «на самом деле Вид и Контроллер могут быть связанными друг с другом непосредственно. Однако, разработчики в основном не используют эту связь»
А если интерисует «физический смысл», то это когда во время работы приложения одни виды сменяют другие (открываются, закрываются) и считается что всем этим ансамблем управляет контроллер
Простите, не очень понятен вопрос. Там прямо под картинкой цитата Фаулера «на самом деле Вид и Контроллер могут быть связанными друг с другом непосредственно. Однако, разработчики в основном не используют эту связь»
А если интерисует «физический смысл», то это когда во время работы приложения одни виды сменяют другие (открываются, закрываются) и считается что всем этим ансамблем управляет контроллер
если совсем кратко то как раз в том что пытались применять MVC, где M — данные а C — логика всего на свете. И контроллер постепенно втягивал в себя все больше и больше кода… в нем на самом деле перемешивалась бизнес логика и логика визуализации данных. И его поддержание превратилось в ад. Причем в этом аду приходилось все время «копаться» потому что программа была живая, с ней работали и давали ценную обратную связь где и что нужно поменять и доработать, какие новые фичи прикрутить. Тут хотелось бы новых программистов нанять но никак потому как Контроллер был центром и вся программа через него была завязана в узел… любое изменение отражалось почти на всем. То есть было нереально выделить отдельные независимые модули которые можно было бы раскидать по нескольким программистам. И пришел момент когда стало понятно что все… оно не способно дальше меняться. Нужно все переписывать нафиг. И вот тогда фасады (не в теории а на практике) и прочие техники для уменьшения связанности стали действительно откровением и волшебной «палочной»
Спасибо… Вы прям из моего подсознания вытащили… у меня тоже всегда было ощущение что нужно разделять понимание MVC и умение работать с тем или иным фреймворком. Только у меня не получалось это так четко сформулировать…
"среди прочих диагнозов может быть" много чего. У меня мама год назад формально умерла от гриппа… А на самом деле от рака желудка и крайнего истощения. Врачи и так ей отводили несколько месяцев. И хотя формально ее убил грипп в прошлом году все понимали что это была смерть от рака. Дядя в этом году умер от того же самого — рак желудка и истощение (вес 48 кг у взрослого мужчины… рак желудка у нас семейное). Но теперь официально он умер от страшной болезни COVID и на фоне всеобщей истерии про рак никто и не вспоминает. Странно что людям так сложно понять что умереть от COVID и умереть от чего угодно при наличии COVID это две совершенно разные вещи. Особенно если учесть возможность того что бессистемно заражена может быть уже довольно большая часть населения. Если так рассуждать то скоро все смерти можно будет списывать на вирус. Кстати увеличение смертности может быть тупо просто следствием коллапса медицинской системы. Не знаю как в других странах, я в Испании, и тут можешь спокойно себе умирать дома от чего угодно. Если это не грипп врачи к тебе неизвестно когда приедут и не факт что приедут вообще (ко мне так никто и не приехал)
Смертность по европе от принятых мер вполне может расти. Я в Испании, медицина в коллапсе, госпитали закрыты и если ты умираешь дома не от Covid а от кишечной инфекции то к тебе просто не приедет врач или приедет через неделю когда ты уже умрешь. Вот статья про Израиль, там вроде бы коллапса нет, но людей настолько запугали и они так боятся подхватить вирус в приемном отделении больницы что сами не идут к врачу и в результате умирают дома… https://www.vesty.co.il/article/Sym11rhgu8
По поводу Модели… Вы правы, если читать лишь описания то и у Барбека и у Краснера действительно написано что модель это доменный объект (любой объект Smalltalk) как вы верно и заметили. А вот на практике всегда был «фасад» между ними. И специальный объект Model от которого наследовались все модели был выделен особо, а это значит что опять таки на практике не любой объект Смоллтолк мог быть моделью. Это то и есть самое интересное. Предполаю что связано это с тем что тогда действительно не было шаблонов, они были «первопроходцами», поэтому практика опережала «теорию». Кстати у Реенскауга в описании фасад тоже появился позже…
А вот насчет бессмысленности разделения UI на вид и контроллер в отрыве от библиотеке… Тут с вами не соглашусь пока. Во второй части попробую показать что это штука довольно универсальная и существующая не только в программах а вообще почти в любом интерфейсе
Когда (и если) возникла необходимость в оптимизации можно перейти к чему-то подобному (2)
Поскольку интерфейс фасада в обоих случаях будет одинаков то на клиенте переход от 1 к 2 никак не отразится. Именно в этом и заключается смысл фасада — можно менять конкретную реализацию бизнесс модели а клиент этого даже не заметит
Грубый пример — поисковый робот который бегает по сети и индексирует где и что находится, чтобы, когда вы обратитесь к поисковику, вам информация была выдана быстро и удобно. Роботу, который в этом случае и будет приложением «все равно на отображение» но тем не менее его работа заключается именно в том чтобы сделать доступ к информации быстрой и удобной.
Мне кажется что в вашем случае (и вообще при работе с базами и не базами) все тоже самое только в предельно упрощенном виде — должно быть некое приложение или модуль в приложении (и этот модуль будет относится именно к доменной модели в терминологии MVC) который знает где находится информация и как ее оптимальным образом извлечь и в удобной форме вернуть для дальнейшего использования. Он может ее просто извлекать, или частично кэшировать для быстрого дальнейшего доступа… не суть важно, важно чтобы именно в доменной модели за эту задачу кто-то отвечал.
И если удобная форма это просто набор строк… То значит этот модуль не должен тащить объекты а должен с помощью SQL запроса извлечь из базы лишь нужные вам строки и вернуть (как и написал Volch). А уж что вы с этими строками будете делать дальше это уже ваше дело — можете отображать, можете для какой-нибудь аналитики или отчетов использовать.
String[] getFIO();
клиент должен получить готовый список из 10 строк с Ф.И.О. людей…
А формироваться этот список должен внутри доменной модели, котороя знает как наиболее оптимальным образом вытащить эти данные из базы или еще откуда. В крайнем случае этот список может формировать фасад… но вообще это опасная дорожка по направлению к тому что фасад начнет реализовывать бизнесс-логику. Просто в вашем примере только база и фасад и мне пока не очень понятно где там находится бизнесс-логика
А если интерисует «физический смысл», то это когда во время работы приложения одни виды сменяют другие (открываются, закрываются) и считается что всем этим ансамблем управляет контроллер
А если интерисует «физический смысл», то это когда во время работы приложения одни виды сменяют другие (открываются, закрываются) и считается что всем этим ансамблем управляет контроллер