прошк прощения за маленький кросспост — но тема уж неоднозначная
Работал я до этого с вэб AJAX проектами
Все там замечательно, я б жил бы и не тужил, но остутсвие элементарных элементов ввода и сложность их написания и всякое такое подвигло миня в сторону WPF
Проет был большой, но прелесть AJAX и JavaScript втом что они динамические
Проект активно развивался и динамически менялся, но на жисть юзера это ника не влияло отрицательно — весь контент кэшировался на клиенте. Если добавлялась новая функциональность — просто грузился скриптик с описанием класса, кэшировался и сразу включался в контекст приложения
Ежели чегото менялось — перезагружался лишь скриптик с измененным классом и система работала по-новому
При этом достигалось следующее:
— Старт приложения был величиной постоянной (контент есть и кэширован)
— изменения и дополнения загружались при необходимости и не отвлекали юзера
При переходе на WPF у меня возникает ощущение невозможности реализации такого функционала
Пока вижу что проект пишется как одно целое (и доставляется с помощью ClickOnce) следовательно:
— каждый день юзер будет ждать (как минимум при 1м запуске) пока обновленное перезагрузится на клиента
— с каждым днем это будет занимать все больше и больше времени
— нет как я понял простого метода разбить проект на сборки по классам и использовать их динамически без раннего связывания (загрузить их динамически с сервера можно, но нужно реализовывать сложные манипуляции и использовать спецфреймворки для реализации плагин-поведения)
Да и забыл еще добавить — у нас в приложении было реализовано до 30 ролей и в каждом минимум 10 классов, а максимум 300 классов (ну эт еще не предел для ваятеля
), реализующих объекты бизнесс-логики
Так вот в вэб приложении каждому юзеру грузились скрипты той роли под которой он зарегистрирован в системе и те скрипты другой роли, которая делегирована ему на время
В WPF получается все эти "приложения" и все все классы должны быть уже в одной сборке приложения!!!
разбивать приложение по ролям — глупо! потому как если юзеру делегированы дополнительные роли — он что должен искать откуда их устанавливать, да и проблемно это все
У нас в интерыейсе был переключатель доступных ролей — переключил роль — поменялся интерфейс и его функциональность — работай на здоровье с приложением данной роли!
все както грустно, а я был такой жизнерадостный рахит, когда впервые увидел ее....WPF, мы влюбились с первого взгляда, но наша любовь бьется об камни будней ...
WPF (или ЦЗА ) — я люблю тибя!!!
Народ помогите влюбленным!
На опушке за околицей мужики строили коровник.
Работали споро и весело. Получалось х**во.
Здравствуйте, akarinsky, Вы писали:
A>Если сможете полюбить так же горячо Silverlight, то могу подсказать, как бороться с Вашими бедами.
A>Сейчас дописываю проект на нем, решал перечисленные Вами задачи без особых трудностей.
Дык они же близнецы и братья!
уже полюбил! подскажите пожалуйста!
На опушке за околицей мужики строили коровник.
Работали споро и весело. Получалось х**во.
Черт, контент-фильтр на работе совсем достал. Отвечу из дома.
На опушке за околицей мужики строили коровник.
Работали споро и весело. Получалось х**во.
Ну тогда давайте перейдем к конкретике.
Нужно помнить, что Silverlight-приложение в виде пакета передается клиенту, где кэшируется в браузере.
При изменении пакета на сервере при след.обращении клиента произойдет обновление и в кэше браузера будет уже актуальная версия.
Вручную управлять обновлением или частичной загрузкой можно, но не представляю в этом необходимости.
Рекомендую первым делом засесть за изучение WCF RIA SERVICES. Зачетнейшая вещь, в разы упрощающая работу по написанию Rich-клиента,
да и серверной стороны тоже.
Как раз доделываю проект при помомощи нее.
Будут конкретные вопросы — welcome.
На опушке за околицей мужики строили коровник.
Работали споро и весело. Получалось х**во.
