Здравствуйте, MaximVK, Вы писали:
MVK>Здравствуйте, henson, Вы писали:
MVK>Резюмируя, ты предлагаешь использовать Prism про запас, авось потом пригодиться. Это сильно похоже на premature optimization, что не есть хорошо.
H>>Масштабируемость значит страдает если количество команд влияет на подходы. MVK>Количество разработчиков всегда влияет на подходы. Возьми крайний случай — один программист, и другой крайний случай — 1000 человек. Команда из десяти человек, конечно, может использовать подходы, которые применяются при разрабоке проектов в 100-200 человек, только это будет крайне неэффективно.
Подходы к построению приложения определяются задачей, а не количеством разработчиков. Например какие-то контролы можно купить, а не писать самому. Опять же количество разработчиков может меняться на разных этапах жизненного цикла приложения.
H>>Prism это больше чем концепция модулей. Может вам он и незачем, а другим вполне подойдет. MVK>Хорошо, а что еще? Какие проблемы решает Prism? Что хорошего он принесет, а что плохого?
Prism дает готовые методы построения легко расширяемых приложений. Для тех, кто не имеет опыта построения таковых, Prism хорошая палочка-выручалочка.
Плохо в нем то, что не годится для постепенного апгрейда существующих приложений. Хотя какие-то отдельные элементы можно взять на вооружение. Еще не годится для игр и вообще для программ состоящих из одного монолитного модуля с незначительными возможностями кастомизации.
Хорошо тем, что позволяет избежать детских болезней роста: когда на определенном этапе приходится переделывать архитектуру, чтобы удовлетворить новые требования заказчика.
Здравствуйте, MaximVK, Вы писали:
MVK>А чем Region из Prism-a лучше, чем ScreenConductor из Calibrum?
Например, Conductor в Caliburn является Screen-ом, значит нужно для него создавать отдельный файл с View. Region в Prism можно приаттачить (через xaml) к любому контролу для которого есть соответствующего RegionAdapter. Это упрощает переиспользование.
Зато в Caliburn (Micro) не работаешь напрямую с View: есть conventions, по которым оно будет создаваться само, при добавлении Screen-а в Conductor.
MVK>Насколько я понимаю, IoC контейнер может быть любой? Если да, то это хорошо.
В Prism — да, они используют CommonServiceLocator.
MVK>Не совсем понятно, кто и управляет жизенным циклом view в этом примере кода.
В примерах Prism для master/detail часто используется Controller, который видит картину на один уровень выше (т.е. и master и detail).
MVK>Вроде как содается по новому view на каждого employee.
Если используются стандартные регионы, то похоже на то.
MVK>Что делать, если у меня будут открыты сотни EmployeeView форм в течении рабочего дня и мне удобнее иметь одну форму, у которой я буду менять привязку к модели (a la Flyweight)? Где Prism предлагает мне разместить эту логику?
Для нетривиального хранения view (во ViewCollection) можно реализовать свой регион (IRegion).
В моем случае master-detail связей много и поэтому я вынес взаимодействие в специальный класс, который это взаимодействие настраивает с помощью fluent интерфейса (описываются потоки данных от одного screen-а к другому, а также зависимости). Сами screen-ы об этом взаимодействие ничего не знают и могут учавствовать почти в любом графе зависимостей (граф превращается в плоский список без повторов в нужном порядке, также отслеживаются циклы). Этот же механизм используется на формах для произвольных master-detail контролов (напр. комбобоксы страна/город/улица) в паре с привязкой.
H>Подходы к построению приложения определяются задачей, а не количеством разработчиков. Например какие-то контролы можно купить, а не писать самому. Опять же количество разработчиков может меняться на разных этапах жизненного цикла приложения.
Честно говоря, не хочется холиворить, но то что ты говоришь — объективно не так. В крупных проектах проблемы reusability возникают уже на уровне приложений, даже не модулей. В компании, где несколько тысяч разработчиков задача улучшения code reuse — это, фактически, отдельный проект(программа), в котором люди работают на постоянной основе. Наличие такой дополнительной боевой единицы — экономически обосновано, попросту говоря экономит денег эта структура больше, чем на нее тратиться. Это также влияет на процесс сбора, структурирования и анализа требований.
Даже если взять простой случай. Пусть есть проект оцененый в 20 ч/л. Оптимальное время для его разработки ориентировочно 16-18 месяцев. Неужели ты думаешь, что подходы (в том числе архитектурные) не поменяются, если тебе его надо будет сделать 30-40-ка разработчиками, но за год.
Кстати, об архитектуре, она также будет зависеть от стуктуры и квалификации команды.
H>Prism дает готовые методы построения легко расширяемых приложений. Для тех, кто не имеет опыта построения таковых, Prism хорошая палочка-выручалочка.
А для тех, кто умеет? Какие аспекты приложения становятся легко расширяемыми с помощью Prism? Что именно становиться легче добавлять, менять?
H>Плохо в нем то, что не годится для постепенного апгрейда существующих приложений. Хотя какие-то отдельные элементы можно взять на вооружение.
Ты имеешь ввиду, что трудно перевести существующее приложение на Prism? А, кстати, насколько легко убираются(заменяются) отдельные компоненты Prism из приложения(я так понимаю IoC фреймворк точно меняется без проблем). И насколько легко переносятся компоненты из приложения написанного с использованием Prism в другие приложения, где Prism не поддерживается?
H>Хорошо тем, что позволяет избежать детских болезней роста: когда на определенном этапе приходится переделывать архитектуру, чтобы удовлетворить новые требования заказчика.
Вот это очень интересный момент. За счет чего это достигается?
В качестве примера: Я не могу сказать это про SCSF. Снять проект с иглы этого фреймворка или даже отдельных его компонентов (например поменять ObjectBuilder на Castle) практически невозможно. Дурацкая концепция workitems стимулирует к смешиванию использования servicelocator-а и IoC контейнера в самых удивительных сочетаниях. И т.д.
Еще раз спасибо за развернутый ответ.
FE>Например, Conductor в Caliburn является Screen-ом, значит нужно для него создавать отдельный файл с View.
Согласно документации — ему, в принципе, все равно:
You may have noticed that Caliburn’s IConductor interface uses the term “item” rather than “screen” and that I was putting the term “screen collection” in quotes. The reason for this is that Caliburn’s conductor implementations do not require the item being conducted to implement IScreen or any particular interface. Conducted items can be POCOs.
FE>Region в Prism можно приаттачить (через xaml) к любому контролу для которого есть соответствующего RegionAdapter. Это упрощает переиспользование.
Вот эту мысль я не понял, пошел курить доку по Prism.
FE>В примерах Prism для master/detail часто используется Controller, который видит картину на один уровень выше (т.е. и master и detail).
Получается, что-то типа аналога WorkItem-а в CAB? Не происходит размазывание логики в таком случае?
FE>В моем случае master-detail связей много и поэтому я вынес взаимодействие в специальный класс, который это взаимодействие настраивает с помощью fluent интерфейса (описываются потоки данных от одного screen-а к другому, а также зависимости). Сами screen-ы об этом взаимодействие ничего не знают и могут учавствовать почти в любом графе зависимостей (граф превращается в плоский список без повторов в нужном порядке, также отслеживаются циклы). Этот же механизм используется на формах для произвольных master-detail контролов (напр. комбобоксы страна/город/улица) в паре с привязкой.
Звучит здорово. Я правильно понимаю, что этот специальный класс знает, что нужно забрать из master скрина и передать в details screen? Ты имеешь ввиду, циклы образуемые master-details связями между скринами типа Сотрудник->Компания->Контакты->Сотрудник? Или циклы между элементами скрина (пример — формульные зависимости между ячейками в экселе)? И еще один вопрос, где ты инициализируешь этот класс?
Здравствуйте, MaximVK, Вы писали:
MVK>Также очень интересно узнать, кто какой фреймворк предпочитает и почему. Также я создал голосовалку http://www.rsdn.ru/poll/3021.aspx
Здравствуйте, MaximVK, Вы писали:
MVK>Согласно документации — ему, в принципе, все равно:
Ему все равно что в него добавить, но предоставленная реализация его самого (ConductorBase и наследники) является Screen-ом (xотя сам интерфейс IConductor не наследник IScreen).
MVK>Получается, что-то типа аналога WorkItem-а в CAB?
Я уже плохо помню подробности, но в SCSF они вроде отделили Controller от WorkItem из-за нарушения SRP.
MVK>Не происходит размазывание логики в таком случае?
Возможно. Можно попробовать поместить её в более высокоуровневый Screen, который видит все связи.
MVK>Я правильно понимаю, что этот специальный класс знает, что нужно забрать из master скрина и передать в details screen?
Да.
MVK>Ты имеешь ввиду, циклы образуемые master-details связями между скринами типа Сотрудник->Компания->Контакты->Сотрудник? Или циклы между элементами скрина (пример — формульные зависимости между ячейками в экселе)?
И те и другие, принципиальной разницы мало.
MVK>И еще один вопрос, где ты инициализируешь этот класс?
Есть специальные инициализаторы, которые ищутся при сканировании сборок IoC-контейнером, но технически можно везде, где можно получить ссылку на этот класс. Иногда удобнее в высокоуровневом screen-е или в конструкторе модуля. Основной вопрос в адресации при повторяющихся типах скринов в разных ветках логического дерева.
Здравствуйте, Codechanger, Вы писали:
C>С моей точки зрения проблема MV* фреймворков в пороге вхождения. Пока ты не понимаешь, зачем он нужен и как его использовать, то и писать ты на нем будешь как привык, а не как следует по внутренней логике. C>В общем, с моей точки зрения, предмет спора не стоит выеденного яйца. Кому-то нравится, кому-то нет. Я писал по-всякому, с MVVM код получается намного стройнее. Опять же, с моей точки зрения, данный код значительно проще поддерживать и расширять. Уфф.Вроде все написал.
Мне кажется, что тут дело не в пороге вхождения, а в стойком ощущении того, что делается лишняя работа. Она вроде как и нужна (тестабилити, мейнтенабилити, а прочие -абилити), но с другой стороны очень уж рутинна. И возникает естественное подсознательное чувство, что это должно быть автоматизируемо. Кто помнит переход от написания DAL-ов ручками к использованию различных ORM фреймворков — думаю, поймет аналогию.
Поэтому это "жу-жу-жу" в умах и на форумах точно не спроста. Значит работа идет и скоро, уверен, можно ждать первых результатов.
P.S. И вообще, люди вечно недовольные текущим положением дел являются в какой-то мере двигателем прогресса.
Еще раз спасибо за дискуссию. Беру таймаут на чтение документации, что поддерживать беседу в конструктивном русле.
P.S. MVK>>Согласно документации — ему, в принципе, все равно: FE>Ему все равно что в него добавить, но предоставленная реализация его самого (ConductorBase и наследники) является Screen-ом (xотя сам интерфейс IConductor не наследник IScreen).
Да, это я протормозил, конечно.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, henson, Вы писали:
H>>Интересно замечание. Я только не понял что значит выставлять модель UI через публичное API. Если вы про ViewModel класс, то он и не предназначен для выставления наружу и вообще служит только как Back End для конкретного View или набора однотипных Views.
S>Нет, это я про использование mv* для автоматизации UI. Очевидно, в этом случае mv-фреймворк будет бесполезен.
А кто говорил про аутомацию UI посредством mv* ?
S>- Во-вторых, для более-менее серьёзного софта нам один фиг придётся давать доступ непосредственно к visual tree и тут mv-фреймворк в лучшем случае нам ничем не поможет, а в худшем — будет только мешать. Тем более что в WPF для контролов _уже_ существует полноценный mv-подход.
I>А кто говорил про аутомацию UI посредством mv* ?
Как минимум для тестов — было точно. И припоминается несколько руководств по использованию MVVM для разделения блоков приложения (т.е. viewModel используется в качестве внутреннего API). Если принципиально — могу понадёргать ссылок.
I>visual tree то зачем выставлять наружу
В основном критично для софта, где надо расширять UI-часть — например, для дополнений к редактору студии.
Здравствуйте, Sinix, Вы писали:
I>>А кто говорил про аутомацию UI посредством mv* ? S>Как минимум для тестов — было точно. И припоминается несколько руководств по использованию MVVM для разделения блоков приложения (т.е. viewModel используется в качестве внутреннего API). Если принципиально — могу понадёргать ссылок.
Топикстартеру нужна это аутомация UI ? По моему он ничего такого не говорил.
I>>visual tree то зачем выставлять наружу S>В основном критично для софта, где надо расширять UI-часть — например, для дополнений к редактору студии.
Ну это сильно сильно сильно узконаправленый и специфичный софт
Здравствуйте, Ikemefula, Вы писали:
I>Топикстартеру нужна это аутомация UI ? По моему он ничего такого не говорил.
Неа, вопрос про автоматизацию начался с моего
Тру-MV фреймворки покрывают очень узкую нишу софта, для которого требуется иметь явную модель UI, но не требуется выставлять эту модель через публичное API.
Также еще добавил ReactiveUI.
