Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, minorlogic, Вы писали:
L>>>Вообще-то это вы высказали мнение, что контроллер может быть не нужен, вам его и доказывать. Но если нет мотивации, то не стоит.
M>>Я не прошу доказывать (это неразумно). Просто поделиться источником информации если есть таковой. Я бегло посмотрел пару описаний MVC и нигде не нашел упоминания об описанных вами обязанностях.
L>Посмотри существующие библиотеки.
Смотрел. Ничего из описанного не встречал.
L> Я вообще ни одной нормальной академической статьи по MVC не видел. Либо заумь, либо ни о чем.
Написана доступно и по делу, тоже статья неправильная?
"Рисунок 3. Диаграмма последовательности MVC." дает представление о взаимодействии MVC, и там совершенно нет ничего что описывается как "контроллер отдает модель вьюхе"
из :
"View ничего брать не откуда не должен, модель ему отдаетсяизвне. Это не обязанность вьюхи.
Правильно, это обязанность контроллера, который якобы "не нужен"."
AS>>В данном случае, если мы хотим иметь возможность отображать что-либо на разных устройствах, то достаточно определить интерфейс модели (вместе с бизнес-логикой) AS>>и пусть этим интерфейсом пользуются различные "представления".
M>Ну да ... это и есть MVC
Я правильно понимаю, то все это растет из того, что в базе данных хранятся данные, а не объекты (с кодом)?
Не расстраивайтесь, этот паттерн никто не понимает. Он слишком долго был мертвым, а воскрешали его не самые лучшие некроманты на примерах "приложение это такая веб страничка, которая показывает содержимое базы данных". Когда начали использовать для чего-то сложнее домашних страничек, мнения разошлись и на данный момент есть десятки реализаций где M, V и C размещены в самых неожиданных местах и комбинациях.
Здравствуйте, minorlogic, Вы писали:
M>>>Я уже подробно ответил, что вам непонятнов ответе? у view нет ответственности знать о происхождении или уметь доставать модель. M>>>model и view связываются извне логикой приложения.
L>>Вот эта "логика приложения" и есть контроллер. А вы говорите, что он не нужен.
M>Не в коем случае.
Ни
M>Повторю в третий раз это вообще не в компетенции MVC компонентов.
Да хоть десять раз повторите, от этого ваша точка зрения яснее не станет.
С каких это пор подсовывание датасорса во view перестало быть компетенцией controller-а?
Шаблон проектирования MVC предполагает разделение данных приложения, пользовательского интерфейса и управляющей логики
Чуть дальше, красненьким:
Это ключевая особенность разделения, которая позволяет работать с моделью, а значит, и с бизнес-логикой приложения, независимо от визуального представления.
Статья конечно косноязычна и достаточно просто разобраться что под "управляющей логикой" и "бизнес логикой" автор имеет в виду совсем разные вещи, но это показательно — я прочел много десятков статей по MVC, и в половине авторы постоянно путаются, где же у них находится логика приложения — в Model или в Controller — и что это такое, "логика приложения" . Постоянно вводятся дополнительные термины вида "бизнес-логика", "управляющая логика", "реакция на действия пользователя", "логика работы" и прочие, части статей как правило противоречат друг другу, представленный в примерах код вида "приложение это страничка, которая показывает содержимое базы данных" .
Это я к тому, что нет единства мнений по поводу архитектуры MVC .
Цитата из википедии:
> модель данных приложения, > пользовательский интерфейс и > управляющая логика > разделены на три отдельных компонента
Потом под "управляющей логикой" начинают понимать "бизнес-логику", которая вообще говоря — часть модели предметной области.
Это ненормально — делить модель предметной области на "данные приложения" и "управляющую логику", ведь ООП как раз предназначено для того,
чтобы объединить поля и методы в объекты — т.е. сделать прямо противоположное!
Если же бизнес-логика относится к модели данных приложения, то что остается в "управляющей" логике?
Я правильно понимаю, то все это растет из того, что в базе данных хранятся данные, а не объекты (с кодом)?
Мне очень нравится подпись кого-то про то, что любая проблема решается введением дополнительного абстратного слоя.
В данном случае, если мы хотим иметь возможность отображать что-либо на разных устройствах, то достаточно определить интерфейс модели (вместе с бизнес-логикой)
и пусть этим интерфейсом пользуются различные "представления".
AS>Это ненормально — делить модель предметной области на "данные приложения" и "управляющую логику", AS>ведь ООП как раз предназначено для того, чтобы объединить поля и методы в объекты
это какой-то неправильный ООП у вас. радикальная исламская ветвь. некошерно.
данные -- это данные. методы их обработки -- это методы их обработки.
допустим, есть метод -- поиск подстроки. он может работать с разными типами данных. а с этими данными в свою очередь может работать кто-то еще...
ну вот у нас есть IPS. это данные (трафик, который мы снифми, и база сигнатур), бизнес-логика, которая ищет эти сигнатуры в трафике, и web-интерфейс. бизнес логика отвязана и от интерфейса и от данных. сегодня это трафик -- завтра это file uploads, вчера сигнатуры -- сегодня это эвристический двиг.
при этом все строго с "заветами" ООП. в частности, веб-интерфйес сношается только с бизнес-логикой и эта бизнес-логика скрывает он него детали оргранизации входных данных.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
1) MV* — классический пример баззворда: все согласны, что это круто, но каждый лепит MV по-разному.
2) Чуть-чуть истории. Олдскульный MVC — это описание приёмов, что применялись при разработке текстового редактора на смоллтоке-80 Затем о MVC вскользь упомянул Фаулер в Patterns of Enterprise Application Architecture.
Controller Model View Controller (MVC) is one of the most quoted (and most misquoted) patterns around. It started as a framework developed by Trygve Reenskaug for the Smalltalk platform in the late 1970s. Since then it has played an influential role in most UI frameworks and in the thinking about UI design.
И панеслась
3) Всегда находятся пуристы, любящие паттерны больше людей. Образуются странные кучки "за MVC — против <вставить нужное>". Причём характер противопоставления абсолютно шизофреничен: у нас view model? Пишем обёртку к данным и долой биндинги
4) Сама концепция mv* — разделение модели и представления. См п.2 — догадываетесь, откуда все эти "мы включили в модель свойства panel 1 и panel 2"? В большей части примеров модель используется для управления сложным UI. О MV на уровне приложения речь заходит куда реже, несмотря на то, что пользы от неё существенно больше.
5) MV на уровне UI в чистом виде абсолютно нежизнеспособна, т.к. не учитывает особенностей UI-фреймворка. Разновидности наподобие MVVM — бесполезны на уровне приложения, т.к. тащат в контроллеры классы из UI-фреймворка, а на уровне отдельных контролов — это всего лишь описание официальных гадлайнов от производителя фреймворка.
6) MV на уровне приложения — полностью ортогонален используемому UI-фреймворку, т.к. направлен на отделение бизнес-логики от UI приложения. Как можно реализовать
По выделенным жирным ссылкам тоже можно узнать мноого нового
AS>Потом под "управляющей логикой" начинают понимать "бизнес-логику", которая вообще говоря — часть модели предметной области.
Ну, смотря что под предметной областью понимать Если предметную область программы — то да. Если предметную область _заказчика_ — то, с чем он работает — то явно нет AS>Это ненормально — делить модель предметной области на "данные приложения" и "управляющую логику", ведь ООП как раз предназначено для того, AS>чтобы объединить поля и методы в объекты — т.е. сделать прямо противоположное!
Не совсем так. ООП главным образом заточено под создание и переиспользование программных компонентов (с минимальными сложностями при обработке напильником). Собственно, поэтому всякие UI-фреймворки в ООП-языках приживаются как родные, а вот сложные модели — увы
Понимаете в чём штука: ваше приложение — это не вся модель деятельности заказчика, а маааленькая её часть. Соответственно, чтоб не привязывать данные к сиюминутным потребностям (а данные заказчику куда важнее самого распрекрасного кода) код и данные можно (и нужно) разделять. AS>Если же бизнес-логика относится к модели данных приложения, то что остается в "управляющей" логике?
Например, "поведение" вашего приложения — всё, кто не относится напрямую к UI AS>Я правильно понимаю, то все это растет из того, что в базе данных хранятся данные, а не объекты (с кодом)?
Нет (см п2 из многобукв) AS>В данном случае, если мы хотим иметь возможность отображать что-либо на разных устройствах, то достаточно определить интерфейс модели (вместе с бизнес-логикой) AS>и пусть этим интерфейсом пользуются различные "представления".
Поздравляю — вы сейчас описали MV-подход на уровне всего приложения
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>Потом под "управляющей логикой" начинают понимать "бизнес-логику", которая вообще говоря — часть модели предметной области. AS>Это ненормально — делить модель предметной области на "данные приложения" и "управляющую логику", ведь ООП как раз предназначено для того, AS>чтобы объединить поля и методы в объекты — т.е. сделать прямо противоположное!
Ничего "противоположного" тут нет: объединение данных и логики одного вида в объекты одновременно является отделением и сокрытием их от данных и логики других видов. Сиречь — инкапсуляцией.
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>В данном случае, если мы хотим иметь возможность отображать что-либо на разных устройствах, то достаточно определить интерфейс модели (вместе с бизнес-логикой) AS>и пусть этим интерфейсом пользуются различные "представления".
Здравствуйте, minorlogic, Вы писали:
AS>>В данном случае, если мы хотим иметь возможность отображать что-либо на разных устройствах, то достаточно определить интерфейс модели (вместе с бизнес-логикой) AS>>и пусть этим интерфейсом пользуются различные "представления".
M>Ну да ... это и есть MVC
Мне показалось, что автор имеет в виду отделенный слой бизнес логики, методы которого вызываются из View. Если я прав, то у него может быть такой код:
class CustomerForm : Form { ...
private void btnSaveCustomer_Click(...)
{
Customer customer = (Customer)cbCustomer.SelectedItem;
CustomerService.Save(customer);
UI.ShowSuccess("Customer has been successfully saved.");
}
А это не MVC. Хотя может быть я не правильно понял то, что имел в виду автор.
Зависит от того какую логику автор имеет в виду. Если логика представления View то это контролер из MVC, Если нет то автор не до конца понимает что такое MVC. MVC распологается на слой выше всей бизнес логики , фактически MVC туп до безобразия.
M> MVC распологается на слой выше всей бизнес логики
Это MCCV — у модели один контроллер, у view — другой и Вы почему-то их разделили, хотя в модели про такое разделение не говорится.
Может это Ваши фантазии?
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>Цитата из википедии:
>> модель данных приложения, >> пользовательский интерфейс и >> управляющая логика >> разделены на три отдельных компонента
AS>Потом под "управляющей логикой" начинают понимать "бизнес-логику", которая вообще говоря — часть модели предметной области.
Как говорил профессор Преображенский, советские газеты не всегда полезны.
Берём английский вариант статьи:
"Model–View–Controller (MVC) is a software architecture,[1] currently considered an architectural pattern used in software engineering. The pattern isolates "domain logic" (the application logic for the user) from the user interface (input and presentation), permitting independent development, testing and maintenance of each (separation of concerns)."
Всё чётко и ясно.
Если есть время — можете подправить русскую статью, люди вам спасибо скажут.
Здравствуйте, Arsen.Shnurkov, Вы писали:
M>> MVC распологается на слой выше всей бизнес логики
AS>Это MCCV — у модели один контроллер, у view — другой и Вы почему-то их разделили, хотя в модели про такое разделение не говорится. AS>Может это Ваши фантазии?
Непонимание только от того что в контролер пытаюстся запихнуть бизнес логику.
А контролер имеет отношение лишь к сложной логике отображения. В простейших случаях MVC контролер вообще не нужен, когда требутся отобразить состояния модели 1 к 1
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, minorlogic, Вы писали:
M>>В простейших случаях MVC контролер вообще не нужен, когда требутся отобразить состояния модели 1 к 1
L>А как тогда view узнает, откуда брать model?
View ничего брать не откуда не должен, модель ему отдаетсяизвне. Это не обязанность вьюхи.
Здравствуйте, minorlogic, Вы писали:
M>>>В простейших случаях MVC контролер вообще не нужен, когда требутся отобразить состояния модели 1 к 1
L>>А как тогда view узнает, откуда брать model?
M>View ничего брать не откуда не должен, модель ему отдаетсяизвне. Это не обязанность вьюхи.
Правильно, это обязанность контроллера, который якобы "не нужен".
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, minorlogic, Вы писали:
M>>>>В простейших случаях MVC контролер вообще не нужен, когда требутся отобразить состояния модели 1 к 1
L>>>А как тогда view узнает, откуда брать model?
M>>View ничего брать не откуда не должен, модель ему отдаетсяизвне. Это не обязанность вьюхи.
L>Правильно, это обязанность контроллера, который якобы "не нужен".
Здравствуйте, minorlogic, Вы писали:
L>>>>А как тогда view узнает, откуда брать model?
M>>>View ничего брать не откуда не должен, модель ему отдаетсяизвне. Это не обязанность вьюхи.
L>>Правильно, это обязанность контроллера, который якобы "не нужен".
M>Не в коем случае. Вы что то путаете.
Здравствуйте, Lloyd, Вы писали:
L>Может быть вы тогда ответите на вопрос: L>
L>А как тогда view узнает, откуда брать model?
L>
Я уже подробно ответил, что вам непонятнов ответе? у view нет ответственности знать о происхождении или уметь доставать модель.
model и view связываются извне логикой приложения.
view может менять модели во время выполнения , модель может менять view во время выполнения. И это все не компетенция MVC компонентов.
Здравствуйте, minorlogic, Вы писали:
M>Я уже подробно ответил, что вам непонятнов ответе? у view нет ответственности знать о происхождении или уметь доставать модель. M>model и view связываются извне логикой приложения.
Вот эта "логика приложения" и есть контроллер. А вы говорите, что он не нужен.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, minorlogic, Вы писали:
M>>Я уже подробно ответил, что вам непонятнов ответе? у view нет ответственности знать о происхождении или уметь доставать модель. M>>model и view связываются извне логикой приложения.
L>Вот эта "логика приложения" и есть контроллер. А вы говорите, что он не нужен.
Не в коем случае. Повторю в третий раз это вообще не в компетенции MVC компонентов.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, minorlogic, Вы писали:
M>>>>Я уже подробно ответил, что вам непонятнов ответе? у view нет ответственности знать о происхождении или уметь доставать модель. M>>>>model и view связываются извне логикой приложения.
L>>>Вот эта "логика приложения" и есть контроллер. А вы говорите, что он не нужен.
M>>Не в коем случае.
L>Ни
M>>Повторю в третий раз это вообще не в компетенции MVC компонентов.
L>Да хоть десять раз повторите, от этого ваша точка зрения яснее не станет. L>С каких это пор подсовывание датасорса во view перестало быть компетенцией controller-а?
У меня нет мотивации вас переубеждать. Если датите источники где написанно о "подсовывание датасорса во view компетенцией controller-а" , с радостью почитаю. Для меня очевидно противоположное хотя бы потому, что пара view — controller могут менять объект модели во время исполнения.
"Как видно, компонентный уровень MVC в языках программирования имеет ряд отступлений от оригинального MVC. Во-первых, отсутствует четкое разделение между представлением и контроллером, в особенности это касается .NET. Во-вторых, в отличие от J2EE, остальные реализации MVC не требуют выделения бизнес-логики приложения в отдельный компонент – модель. Программист самостоятельно принимает решение: тратить изрядные усилия по выделению в приложении модели или же сразу описывать в контроллере обработку данных, к примеру, обращения к базе данных.
Второе решение приводит к проблеме проектирования, для борьбы с которой и был создан шаблон MVC: если не выделить отдельную сущность – модель, избежать зависимости бизнес-логики от контроллера невозможно. Зачастую ему следуют неопытные программисты, которые в силу незнания считают его единственно возможным."
Наделять контролер бизнес логикой приложения это одна из распространенных ошибок.
Здравствуйте, minorlogic, Вы писали:
L>>Да хоть десять раз повторите, от этого ваша точка зрения яснее не станет. L>>С каких это пор подсовывание датасорса во view перестало быть компетенцией controller-а?
M>У меня нет мотивации вас переубеждать. Если датите источники где написанно о "подсовывание датасорса во view компетенцией controller-а" , с радостью почитаю.
Вообще-то это вы высказали мнение, что контроллер может быть не нужен, вам его и доказывать. Но если нет мотивации, то не стоит.
M>Для меня очевидно противоположное хотя бы потому, что пара view — controller могут менять объект модели во время исполнения.
Заметь, пара, а не view.
M>Наделять контролер бизнес логикой приложения это одна из распространенных ошибок.
Здравствуйте, Lloyd, Вы писали:
L>Вообще-то это вы высказали мнение, что контроллер может быть не нужен, вам его и доказывать. Но если нет мотивации, то не стоит.
Я не прошу доказывать (это неразумно). Просто поделиться источником информации если есть таковой. Я бегло посмотрел пару описаний MVC и нигде не нашел упоминания об описанных вами обязанностях.
Здравствуйте, minorlogic, Вы писали:
L>>Вообще-то это вы высказали мнение, что контроллер может быть не нужен, вам его и доказывать. Но если нет мотивации, то не стоит.
M>Я не прошу доказывать (это неразумно). Просто поделиться источником информации если есть таковой. Я бегло посмотрел пару описаний MVC и нигде не нашел упоминания об описанных вами обязанностях.
Посмотри существующие библиотеки. Я вообще ни одной нормальной академической статьи по MVC не видел. Либо заумь, либо ни о чем.
Здравствуйте, minorlogic, Вы писали:
M>>>Я не прошу доказывать (это неразумно). Просто поделиться источником информации если есть таковой. Я бегло посмотрел пару описаний MVC и нигде не нашел упоминания об описанных вами обязанностях.
L>>Посмотри существующие библиотеки.
M>Смотрел. Ничего из описанного не встречал.
M>Написана доступно и по делу, тоже статья неправильная?
M>"Рисунок 3. Диаграмма последовательности MVC." дает представление о взаимодействии MVC, и там совершенно нет ничего что описывается как "контроллер отдает модель вьюхе"
Там не в чистом виде тройка MVC, так еще и команды добавлены. Если ты их уберешь, то их функционал создания и инициализации view уйдет в контроллеры, и как раз получится то, что я и написал — "контроллер отдает модель вьюхе".
M>>Написана доступно и по делу, тоже статья неправильная?
M>>"Рисунок 3. Диаграмма последовательности MVC." дает представление о взаимодействии MVC, и там совершенно нет ничего что описывается как "контроллер отдает модель вьюхе"
L>Там не в чистом виде тройка MVC, так еще и команды добавлены. Если ты их уберешь, то их функционал создания и инициализации view уйдет в контроллеры, и как раз получится то, что я и написал — "контроллер отдает модель вьюхе".
Ни в преведенной диграме ни в статье этого нет. Дело в том, что вьюха как и контролер могут менять модель на лету. В некоторых случаях один и тот же контролер может взаимодействовать с разными вьюхами. Одна и та же модель с разными вьюхами.
Из этого напрямую следует , что связывание модели вьюхи и контролера это внешняя по отношению к MVC функциональность. Контролеру вполне можно заменить представление , например различные варианты ColorPicker при этом контролер совсем не обязан знать о конкретной имплементации ColorPicker а лишь обеспечит реакцию на событие "выбрали цвет".
Здравствуйте, minorlogic, Вы писали:
M>>>"Рисунок 3. Диаграмма последовательности MVC." дает представление о взаимодействии MVC, и там совершенно нет ничего что описывается как "контроллер отдает модель вьюхе"
L>>Там не в чистом виде тройка MVC, так еще и команды добавлены. Если ты их уберешь, то их функционал создания и инициализации view уйдет в контроллеры, и как раз получится то, что я и написал — "контроллер отдает модель вьюхе".
M>Ни в преведенной диграме ни в статье этого нет.
Да без разницы. Если ты оставляешь только тройку MVC, то получишь именно то, о чем я и писал. Если ты вводишь дополнительные сущности и выносишь в них функционал, который ранее относился к controller-у, то получить можешь все что угодно. Я писал о варианте именно MVC, а не о "MVC + что-то еще".
M>Дело в том, что вьюха как и контролер могут менять модель на лету. В некоторых случаях один и тот же контролер может взаимодействовать с разными вьюхами.
Может, но это не относится к предмету обсуждения.
M>Одна и та же модель с разными вьюхами.
Не стоит.
M>Из этого напрямую следует , что связывание модели вьюхи и контролера это внешняя по отношению к MVC функциональность. Контролеру вполне можно заменить представление , например различные варианты ColorPicker при этом контролер совсем не обязан знать о конкретной имплементации ColorPicker а лишь обеспечит реакцию на событие "выбрали цвет".
Смотри выше. Вы ввели дополнительную сущность, внешнюю по отношению к обсуждаемой тройке MVC. Конечно, в этом случае можно прийти к другим выводам.
Мне все больше кажется, что у вас искаженные представления про MVC.
L>Здравствуйте, minorlogic, Вы писали:
M>>>>"Рисунок 3. Диаграмма последовательности MVC." дает представление о взаимодействии MVC, и там совершенно нет ничего что описывается как "контроллер отдает модель вьюхе"
L>>>Там не в чистом виде тройка MVC, так еще и команды добавлены. Если ты их уберешь, то их функционал создания и инициализации view уйдет в контроллеры, и как раз получится то, что я и написал — "контроллер отдает модель вьюхе".
M>>Ни в преведенной диграме ни в статье этого нет.
L>Да без разницы. Если ты оставляешь только тройку MVC, то получишь именно то, о чем я и писал. Если ты вводишь дополнительные сущности и выносишь в них функционал, который ранее относился к controller-у, то получить можешь все что угодно. Я писал о варианте именно MVC, а не о "MVC + что-то еще".
MVC это не модель приложения. Это шаблон описывающий компоненты для построения UI. Так же как и шаблон "Сингелтон" не описывает приложение так и MVC. дальше больше , MVC реализация не относится к приложению как 1 к 1 а как N к M. Приложение может иметь много разных MVC применений , так и одна реализация MVC может быть использована разными приложениями.
M>>Дело в том, что вьюха как и контролер могут менять модель на лету. В некоторых случаях один и тот же контролер может взаимодействовать с разными вьюхами.
L>Может, но это не относится к предмету обсуждения.
Относится , это утверждение противеречит утверждению что контролер занимается управлением временем жизни и инстансами других сущностей MVC.
M>>Одна и та же модель с разными вьюхами.
L>Не стоит.
Это одна из ключевых особенностей MVC, таблица может быть отображена как
1. список значений
2. график
3. ....
или как все сразу одновременно.
M>>Из этого напрямую следует , что связывание модели вьюхи и контролера это внешняя по отношению к MVC функциональность. Контролеру вполне можно заменить представление , например различные варианты ColorPicker при этом контролер совсем не обязан знать о конкретной имплементации ColorPicker а лишь обеспечит реакцию на событие "выбрали цвет".
L>Смотри выше. Вы ввели дополнительную сущность, внешнюю по отношению к обсуждаемой тройке MVC. Конечно, в этом случае можно прийти к другим выводам.
я не вводил. Это априори подразумевается , как и то что класс std::string это не приложение а лишь кирпичик который может быть использован.
Здравствуйте, minorlogic, Вы писали:
M>Мне все больше кажется, что у вас искаженные представления про MVC.
Давайте остановимся на формулировке, что оно у нас разное, дабы не скатываться на личности.
M>>>Ни в преведенной диграме ни в статье этого нет.
L>>Да без разницы. Если ты оставляешь только тройку MVC, то получишь именно то, о чем я и писал. Если ты вводишь дополнительные сущности и выносишь в них функционал, который ранее относился к controller-у, то получить можешь все что угодно. Я писал о варианте именно MVC, а не о "MVC + что-то еще".
M>MVC это не модель приложения. Это шаблон описывающий компоненты для построения UI.
MVC вполне может быть использован в этом качестве.
M>Так же как и шаблон "Сингелтон" не описывает приложение так и MVC. дальше больше , MVC реализация не относится к приложению как 1 к 1 а как N к M. Приложение может иметь много разных MVC применений , так и одна реализация MVC может быть использована разными приложениями.
Зависит от того, что вы вкладываете в эти понятия.
M>>>Дело в том, что вьюха как и контролер могут менять модель на лету. В некоторых случаях один и тот же контролер может взаимодействовать с разными вьюхами.
L>>Может, но это не относится к предмету обсуждения.
M>Относится , это утверждение противеречит утверждению что контролер занимается управлением временем жизни и инстансами других сущностей MVC.
Не противоречит. Контроллер вполне может менять модель при этом занимаясь вышеперечитенным. Нет противоречия.
M>>>Одна и та же модель с разными вьюхами.
L>>Не стоит.
M>Это одна из ключевых особенностей MVC, таблица может быть отображена как M>1. список значений M>2. график M>3. ....
M>или как все сразу одновременно.
Полная фраза звучала так: "одна и та же модель [может взаимодействовать] с разными вьюхами". В выше приведенном списке речь идет о другом взаимодействии: view -> model, а не наоборот.
M>>>Из этого напрямую следует , что связывание модели вьюхи и контролера это внешняя по отношению к MVC функциональность. Контролеру вполне можно заменить представление , например различные варианты ColorPicker при этом контролер совсем не обязан знать о конкретной имплементации ColorPicker а лишь обеспечит реакцию на событие "выбрали цвет".
L>>Смотри выше. Вы ввели дополнительную сущность, внешнюю по отношению к обсуждаемой тройке MVC. Конечно, в этом случае можно прийти к другим выводам.
M>я не вводил. Это априори подразумевается ,
On 30.10.2010 21:19, Arsen.Shnurkov wrote:
> Я правильно понимаю, то все это растет из того, что в базе данных хранятся > данные, а не объекты (с кодом)?
Да, даннные. И да, это обобщение MVC на 3-слойные приложения -- бредятина.
Непонимание только от того что в контролер пытаюстся запихнуть бизнес логику. А контролер имеет отношение лишь к сложной логике отображения. В простейших случаях MVC контролер вообще не нужен, когда требутся отобразить состояния модели 1 к 1
Про простейший случай соглашусь. А расхождения идут в следующих местах:
1. Модель — это только данные в базе данных, данные и валидаторы или данные и логика?
2. Что делать если у нас не веб станичка а программа и действия пользователя приходят от тех же окошек, что и view? Каково при этом место контроллера?
3. Push или Pull? И если push, то куда?
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>Я бы даже сказал, что Document-View из MFC как-то ближе к жизни.
Это тоже вариант MVC. MVC это даже не совсем паттерн, это концепция разделения обязанностей. Если перевести это в паттерны реализации, то это будет целое семейство паттернов. Споры на счет MVC от того, что люди хотят видеть конкретный перечень обязанностей и красивые картинки классов со связями. Тот же Кент Бек, Фаулер или Эрих Гамма сотоварищи по нескольку раз повторяют что паттерны не используются вчистую, их всегда нужено адаптировать под конкретную специфику. В чистом виде они нужны в основном как словарь терминов для облегчения общения.
Материал из Википедии — свободной энциклопедии, -_*
Непонимание только от того что в контролер пытаюстся запихнуть бизнес логику. А контролер имеет отношение лишь к сложной логике отображения. В простейших случаях MVC контролер вообще не нужен, когда требутся отобразить состояния модели 1 к 1
EOH>Про простейший случай соглашусь. А расхождения идут в следующих местах: EOH>1. Модель — это только данные в базе данных, данные и валидаторы или данные и логика?
Никакого отношения к БД. Это "Модель Данных", которая предоставляет интерфейс доступа к данным и интерфейс внешнего воздействия (пользовательского). И конечно это данные и логика.
EOH>2. Что делать если у нас не веб станичка а программа и действия пользователя приходят от тех же окошек, что и view? Каково при этом место контроллера?
Место контролера преобразовать сообщения от окошек (контролов) в действия над моделью.
EOH>3. Push или Pull? И если push, то куда?
Никакого отношения к БД. Это "Модель Данных", которая предоставляет интерфейс доступа к данным и интерфейс внешнего воздействия (пользовательского). И конечно это данные и логика. Место контролера преобразовать сообщения от окошек (контролов) в действия над моделью.
Вот я с вами соглашусь. А во многих книжках, блогах и статьях по-другому написано.
3. Push или Pull? И если push, то куда?
Active model / passive model — как именно крепить части системы друг к другу.
Ну мало ли чего пишут на стенах. Кто то пытается этот патерн на веб приложения натянуть кто то еще куда...
Вообще-то его воскресили как раз веб приложения. Он был мертв со времени smalltalk. А из могилы его подняли, когда php домашние страницы-переростки начали гнить и разваливаться под собственным весом. И тогда неожиданно поняли, что эмбеддить SQL в HTML это не очень хорошо, и начали делить на основании MVC. Ну а потом и массы подтянулись (с).
Ну мало ли чего пишут на стенах. Кто то пытается этот патерн на веб приложения натянуть кто то еще куда...
EOH>Вообще-то его воскресили как раз веб приложения. Он был мертв со времени smalltalk. А из могилы его подняли, когда php домашние страницы-переростки начали гнить и разваливаться под собственным весом. И тогда неожиданно поняли, что эмбеддить SQL в HTML это не очень хорошо, и начали делить на основании MVC. Ну а потом и массы подтянулись (с).
Не могу судить . Я с веб разработкой не сталкивался , а с MVC познакомился в 2000 году при разработке десктопного приложения, расчитанного на легкое портирование.
Не могу судить . Я с веб разработкой не сталкивался , а с MVC познакомился в 2000 году при разработке десктопного приложения, расчитанного на легкое портирование.
Если не секрет — в рамках какого-то фреймворка, или с нуля писали? Document-View от Microsoft был давно, но он не был популярен.
Не могу судить . Я с веб разработкой не сталкивался , а с MVC познакомился в 2000 году при разработке десктопного приложения, расчитанного на легкое портирование.
EOH>Если не секрет — в рамках какого-то фреймворка, или с нуля писали? Document-View от Microsoft был давно, но он не был популярен.
Писали с нуля , потом обнаружили что подход который мы применяем уже описан как MVC. Document-View от Microsoft не прижился , скорее изза имплементации.
.
).
Затем о MVC вскользь 
