Здравствуйте, pintelou, Вы писали:
P>Общеее замечание по паттерну MVC — коллеги, а вас нет такого впечатления, что практически каждое упоминание этого паттерна вызывает оживленную дискуссию о роли и функциях контроллера? Это наводит на мысли, что паттерн все же определен недостаточно удачно...
Или наоборот — слишком удачно. Ведь обсуждается-то не вопрос о том, применять его или нет, а то, как именно его реализовывать и применять.
По-моему дело тут в том, что MVC — это не просто конкретный шаблон — вроде той же Factory, а скорее некое общее архитектурное решение. Ведь в общем случае и Model и View и Controller — это не просто отдельные классы, а скорее целые слои.
Re[3]: MVC pattern программирования. Вопросы по идеологии.
D>На мой взгляд все несколько иначе: вид не должен имеет ссылку на модель, как вы указали, точно также модель ничего не должна знает о текущем виде. Модель и вид посылают сообщения друг другу только посредством интерфейса контроллера. Т.е. только интерфейс контроллера обеспечивает взаимодействие модели и вида. Таким образом, легко реализуется заменяемость видов и контроллеров.
В документации к библиотеке классов SFL (Stingray Foundation Library), которая входит в состав ихнего Grid-а (и других продуктов), говорится что у вида есть ссылка на модель, но эта сссылка должна быть слабой. В их примерах класс, реализующий конкретный вид, содержит указатель на базовый библиотечный класс модели (из которого порождена конкретная модель).
Re[13]: MVC pattern программирования. Вопросы по идеологии.
Здравствуйте, Dimetrius, Вы писали:
D>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Здравствуйте, Dimetrius, Вы писали:
D>>>Адаптеры и фасады и не являются частью контроллера...если говорить, о фасаде модели, то он просто предоставляет унифицированный интерфейс модели, а уже контроллер использует этот интерфейс с целью организации взаимодействия с видами(видом). Я это именно так понимаю
AF>>Согласен. Я и не считаю их частью контроллера. В принципе их конечно модно было бы отнести к модели, однако если рассматривать сценарий, когда нам требуется не меняя модель добавлять к ней дополнительные интерфейсы — для того, что бы показывать её данные в некотором новом представлении, то получается, что адаптеры стоит вынести в отдельный слой. Этот слой (слой адаптеров), расположен над слоем модели и используется контроллером для конфигурирования представлений.
D>к чему относить фасады и адаптеры, на мой взгляд, вопрос, который должен решаться в контексте поставленной задачи или в соотвествии с собственными вкусами(если контекст задачи явно не подсказывает решение)...У меня были случаи, когда приходилось выделять фасад модели в отдельный слой(класс) между моделью и контроллером, а было и так что я просто интегрировал фасад в модель(в интерфейс корня иерархии классов модели)- но это, на мой взгляд, целесообразно для небольших моделей...самое главное из всего вышесказанного то, что модель должна иметь унифицированный интерфейс по отношению к контроллеру, а как его реализовать-это по обстоятельствам
В той же Stringray Foundation Library предлагают для этого дела так называемую presentation model, которую можно вставлять между видом и основной моделью (кажется это похоже на то, что здесь описывают). Там рассматривается пример, очень схожий с тем, который приводил ][tiger насчет файловой структуры.
В их примере они рассматривают, кажется, абстрактную программу для разработки электрических схем. В этом примере, отдельные виды могут не хотеть знать о том, что они отображают именно элементы элетрической схемы — и поэтому эти виды обращаются за данными не к основной модели, а к презентационной модели (которая поставляет виду только визуальные характеристики элементов).
Re[14]: MVC pattern программирования. Вопросы по идеологии.
Здравствуйте, LamerDrv, Вы писали:
LD>В той же Stringray Foundation Library предлагают для этого дела так называемую presentation model, которую можно вставлять между видом и основной моделью (кажется это похоже на то, что здесь описывают). Там рассматривается пример, очень схожий с тем, который приводил ][tiger насчет файловой структуры.
Собственно это мы и обсуждали. Вопрос был только лишь в том, к кому из троицы модель-представление-контроллер или к кому-то четвёртому относить функцию преобразования интерфейса модели к интерфейсу вида. Вот тут мнения разделились...
LD>В их примере они рассматривают, кажется, абстрактную программу для разработки электрических схем. В этом примере, отдельные виды могут не хотеть знать о том, что они отображают именно элементы элетрической схемы — и поэтому эти виды обращаются за данными не к основной модели, а к презентационной модели (которая поставляет виду только визуальные характеристики элементов).
Да, это стандартное решение. Аналогичные решения используются во многих САПР, например. Там есть универсальный редактор, который ничего не знает о модели, которую он редактирует, а так же модель, которая не в курсе насчёт редактора. Но между ними есть слой, который преобразует интерфейсы объектов модели в понятный представлению (редактору) вид.
Re[4]: MVC pattern программирования. Вопросы по идеологии.
LD>В документации к библиотеке классов SFL (Stingray Foundation Library), которая входит в состав ихнего Grid-а (и других продуктов), говорится что у вида есть ссылка на модель, но эта сссылка должна быть слабой. В их примерах класс, реализующий конкретный вид, содержит указатель на базовый библиотечный класс модели (из которого порождена конкретная модель).
Не буду спорить с создателями SFL, у них, очевидно, в силу реализации подобного подхода были какие-то свои мотивы Я постараюсь объяснить какие недостатки я вижу в этом подходе:
1. невозможность унифицированного контроля потоков сообщений и данных между моделью и видом
2. модели отображаемые видом вовсе не обязательно пораждаются от одного абстракного класса
Re: MVC pattern программирования. Вопросы по идеологии.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте. Возникли следущие вопросы по MVC.
А>1. Есть объект типа "набор объектов", что хранить у него в Model? Model'ы объектов, или их контроллеры.
А>2. Где надо хранить функции работы с моделью? Функции типа: добавить в набор еще один объект, удалить из набора объект, etc. Если в контроллере, то как быть с private данными Model'и, а если еще и в Model'е то, ИМХО, переусложнение.
А>Спасибо.
Ведь обсуждается-то не вопрос о том, применять его или нет, а то, как именно его реализовывать и применять. 
