Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, gandjustas, Вы писали:

C>>>1) Что кэшировать-то? Вот я нажал на ячейку — и мне надо показать подробные детали для неё. Шансы что я нажму на неё второй раз — не особо велики.
G>>Вот подробные детали и кешируй. Даже если второй раз запрошено никогда не будет это не даст заметного оверхеда. Причем кеш ответов не вносит оверхед в отличе от кеширования данных.
C>Торможение в первый раз — уже неприемлимо.
Да ты че? а как же 5 метров первая загрузка?

C>>>2) Как инвалидировать будем-с?
G>>last modified
C>Это требует _каждый_ _раз_ делать запрос на сервер при нажатии на ячейку. Пофиг что оно вернёт "304 Not Modified" — всё равно нужен отдельный запрос.
Ну да, с каналом в 1,5 мбит это пройдет незаметно.

C>>>Хранимые процедуры, триггеры, CTE — уже не имеют никакого отношения к реляционной алгебре. Соответственно, глупо утверждать что программа с большим числом хранимок и триггеров более "реляционна", чем программа с H/ORM.
G>>Как раз можно, томому что теже триггеры и CTE работают именно с реляционными данными, тогда как H/ORM хочет сделать вид что работа идет с объектами.
C>Нет, H/ORM работает с объектным представлением реляционных данных.
Мало маслянное.

C>Сам по себе H/ORM так же "реляционен" как и голый SQL.
Ты видимо не понимаешь что означает термин "реляцонный".

C>>>Ты не учитываешь, что некоторые изменения должны делаються очень быстро. Если координатор, который должен распределить пару тысяч смен, должен по 10 секунд ждать на каждую операцию — он придёт к тебе домой и тебя застрелит.
G>>Ну да, выдумывание небылиц — хороший способ обоснования свой позиции, с чего ты взял 10 секунд?
C>Даже пара секунд — уже много. Уже даже доли секунды — слишком много.
Ну да, у тебя тоже реалтайм софт по управлению ядерным реактором?
Задержка в пределах секунды для сохранения — вполне нормально.

G>>Даже если взять того же оператора и представить что пересчет аггрегатов в запросе выполняется в 100 раз быстрее 0.1 секунду, то на отображение 10000 записей ему придется ждать около 20 минут. И это прижедтся испытать каждому пользователю, который попытается просмотреть расписание.
C>Ты забываешь, что в том виде, который смотрит координатор никакие сложные аггрегаты не считаются.
В другом считаются, без разницы.

C>>>Я говорю не про FK. Я уже привёл пример, когда изменение одного кусочка данных повляет на другой, не связанный напрямую с ним.
G>>И что? Ты создавая программу не знаешь какие действия на какие данные повлияют?
C>Не знаю. Поэтому и сделал систему, где мне и знать это необязательно.


C>>>Нет. Лишний расход траффика — у тебя. У меня сейчас дневной расход на приложение — около 10Мб. 5Мб на начальную загрузку (надо бы её оптимизировать...), а дальше считанные байты на трансляцию изменений.
G>>
G>>А в моем подходе не будет начальной загрузки и теже 5 метров будут растянуты по времени. И потом тоже будут "считанные байты" на изменения.
C>Не будут. У тебя загрузка одного вида займёт в лучшем случае килобайт 500. А их переключают кучу десятков раз в день.
Давай не будем мерятся качаемыми данными, в твоем случае в среднем получится больше.

C>>>Т.е. оно реально может использоваться на модеме.
G>>
G>>Я плакал
C>Плачь. Требование реально.
Как ты 5 метров на модеме выкачаешь?.

C>>>Для твоей модели оно недостижимо.
G>>Ну я как раз через GPRS часто в интернете сижу. Если бы мне кто-нибудь предложил скачать 5 метров просто чтобы начать пользоваться программой, то я бы сразу послал такой сервис.
C>А твой сервис с торможением по минуте на _каждое_ действие пошлют ещё дальше.
Уже минуты... хорошо ты выдумываешь...
Время работы сервера в случае GPRS пренебрежительно мало по сравенинию со всеменем передачи данных.

G>>Короче хватит практиковаться в выдумывании небылиц. Адекватного описания преимуществ твоего подхода не видно, а все что есть вполне делается и без h\orm.
C>Ну да. Твой подход требует:
C>1) Большого расхода времени.
Докажи

C>2) В 10-100 раз большего количества серверов.
Докажи

C>3) Гораздо более сложного программирования — ручного отслеживания зависимостей.
Это зависит от структуры программы. В моем случае все зависимости явные.

C>4) Мешанины UDF, SP и прочих "радостей".
Которые улучшают производительность и уменьшают нагрузку на сеть.

C>5) Зависимость от конкретной БД.
Какой ужас...

C>6) Не будет работать на модеме.
Будет лучше чекм твой вариант

Короче не выдумывай небылицы.

Здравствуйте, gandjustas, Вы писали:

C>>Торможение в первый раз — уже неприемлимо.
G>Да ты че? а как же 5 метров первая загрузка?
Не строй дурачка. Разовая трата в 5Мб допустима, а вот торможение на КАЖДОЙ операции — нет.

G>>>last modified
C>>Это требует _каждый_ _раз_ делать запрос на сервер при нажатии на ячейку. Пофиг что оно вернёт "304 Not Modified" — всё равно нужен отдельный запрос.
G>Ну да, с каналом в 1,5 мбит это пройдет незаметно.
А с GPRS?

Да и вовсе не так незаметно.

C>>Сам по себе H/ORM так же "реляционен" как и голый SQL.
G>Ты видимо не понимаешь что означает термин "реляцонный".
Относящийся к реляционной алгебре.

G>>>Ну да, выдумывание небылиц — хороший способ обоснования свой позиции, с чего ты взял 10 секунд?
C>>Даже пара секунд — уже много. Уже даже доли секунды — слишком много.
G>Ну да, у тебя тоже реалтайм софт по управлению ядерным реактором?
Нет, софт которым пользуются люди.

G>Задержка в пределах секунды для сохранения — вполне нормально.
Там нет "сохранения". Есть мгновенная реакция — пользователь тыкнул, и должен сразу быть ответ.

C>>Ты забываешь, что в том виде, который смотрит координатор никакие сложные аггрегаты не считаются.
G>В другом считаются, без разницы.
А там где считаются — оно не создаёт проблем.

G>>>А в моем подходе не будет начальной загрузки и теже 5 метров будут растянуты по времени. И потом тоже будут "считанные байты" на изменения.
C>>Не будут. У тебя загрузка одного вида займёт в лучшем случае килобайт 500. А их переключают кучу десятков раз в день.
G>Давай не будем мерятся качаемыми данными, в твоем случае в среднем получится больше.
Голословно. Я тебе уже показал ДВА РАЗНЫХ вида (а всего их 8 штук, и ещё добавляются новые) одних и тех же данных. Между ними пользователи переключаются раз в пару минут. Как в твоём случае сделать переключение быстрым?

Ты так и не ответил.

G>>>Я плакал
C>>Плачь. Требование реально.
G>Как ты 5 метров на модеме выкачаешь?.
Без проблем. Около 40 минут времени.

Впрочем, этих 5Мб уже не стало. Вот только что закоммитил в staging поддержку персистентного локального кэша.

C>>А твой сервис с торможением по минуте на _каждое_ действие пошлют ещё дальше.
G>Уже минуты... хорошо ты выдумываешь...
На передачу 500Кб данных.

G>Время работы сервера в случае GPRS пренебрежительно мало по сравенинию со всеменем передачи данных.
Именно.

C>>Ну да. Твой подход требует:
C>>1) Большого расхода времени.
G>Докажи
Обращение к серверу на каждое действие. А это задержки.

C>>2) В 10-100 раз большего количества серверов.
G>Докажи
Выполнение ВСЕХ действий на сервере. У меня сервер, фактически, загружен только рассылкой изменений и простыми мутирующими операциями. Всё остальное делается на клиентах.

C>>3) Гораздо более сложного программирования — ручного отслеживания зависимостей.
G>Это зависит от структуры программы. В моем случае все зависимости явные.
Значит оно примитивное.

C>>4) Мешанины UDF, SP и прочих "радостей".
G>Которые улучшают производительность и уменьшают нагрузку на сеть.
Твоя архитектура вся уменьшает производительность и увеличивает нагрузку на сеть.

C>>5) Зависимость от конкретной БД.
G>Какой ужас...
Да.

C>>6) Не будет работать на модеме.
G> Будет лучше чекм твой вариант
G>Короче не выдумывай небылицы.
Ты всё более неадекватен.

Таки предложи как сделать лучше чем моё решение. Критерии я написал выше (6 пунктов). Ждёмс....

Вот такие вот элегантные L/ORM.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, gandjustas, Вы писали:

C>>>Торможение в первый раз — уже неприемлимо.
G>>Да ты че? а как же 5 метров первая загрузка?
C>Не строй дурачка. Разовая трата в 5Мб допустима, а вот торможение на КАЖДОЙ операции — нет.
какое-то торможение ты сам придумал, даже 200 мс латентности канала не дадут заметной для пользователя задержки, а суммарный объем загружаемых данных за одну "сессию" работы будет меньше, чем у тебя.

G>>>>last modified
C>>>Это требует _каждый_ _раз_ делать запрос на сервер при нажатии на ячейку. Пофиг что оно вернёт "304 Not Modified" — всё равно нужен отдельный запрос.
G>>Ну да, с каналом в 1,5 мбит это пройдет незаметно.
C>А с GPRS?
С GPRS бужет немного заметно, но этогораздо лучше, чем ожидать загрузки 5 мб.

C>>>Сам по себе H/ORM так же "реляционен" как и голый SQL.
G>>Ты видимо не понимаешь что означает термин "реляцонный".
C>Относящийся к реляционной алгебре.
Ну и как объекты H/ORM относятся к реляционной алгебре. (Подсказка — никак)

G>>>>Ну да, выдумывание небылиц — хороший способ обоснования свой позиции, с чего ты взял 10 секунд?
C>>>Даже пара секунд — уже много. Уже даже доли секунды — слишком много.
G>>Ну да, у тебя тоже реалтайм софт по управлению ядерным реактором?
C>Нет, софт которым пользуются люди.
Люди пользуются миллионами сайтов, который работает как я описываю.
И может быть единицами программ, которые работаю как ты описываешь

G>>>>А в моем подходе не будет начальной загрузки и теже 5 метров будут растянуты по времени. И потом тоже будут "считанные байты" на изменения.
C>>>Не будут. У тебя загрузка одного вида займёт в лучшем случае килобайт 500. А их переключают кучу десятков раз в день.
G>>Давай не будем мерятся качаемыми данными, в твоем случае в среднем получится больше.
C>Голословно. Я тебе уже показал ДВА РАЗНЫХ вида (а всего их 8 штук, и ещё добавляются новые) одних и тех же данных. Между ними пользователи переключаются раз в пару минут. Как в твоём случае сделать переключение быстрым?
Да так же как в твоем, показывать последний сохраненный ответ.
Это к вопросу о передаваемых данных не имеет отношения/

G>>>>Я плакал
C>>>Плачь. Требование реально.
G>>Как ты 5 метров на модеме выкачаешь?.
C>Без проблем. Около 40 минут времени.


C>Впрочем, этих 5Мб уже не стало. Вот только что закоммитил в staging поддержку персистентного локального кэша.
И ты только сейчас догадался сделать персистентный кеш?
Я бы с этого начал
Кстати кеш в HTTP персистентный в большинстве случаев.

C>>>А твой сервис с торможением по минуте на _каждое_ действие пошлют ещё дальше.
G>>Уже минуты... хорошо ты выдумываешь...
C>На передачу 500Кб данных.
А откуда передача 500 кб данных? Это будет делаться максимум один раз.

G>>Время работы сервера в случае GPRS пренебрежительно мало по сравенинию со всеменем передачи данных.
C>Именно.
Ну так лучше сократить время передачи и нагрузить севрер рассчетами, что я собственно и предлагаю.

C>>>Ну да. Твой подход требует:
C>>>1) Большого расхода времени.
G>>Докажи
C>Обращение к серверу на каждое действие. А это задержки.
Но суммарно это время будет меньше времени выкачивания 5 мб.
Кроме того эти задержки вполне возможно сделать незаметными.

C>>>2) В 10-100 раз большего количества серверов.
G>>Докажи
C>Выполнение ВСЕХ действий на сервере. У меня сервер, фактически, загружен только рассылкой изменений и простыми мутирующими операциями. Всё остальное делается на клиентах.
То есть у тебя сервер только зря греет воздух.

C>>>3) Гораздо более сложного программирования — ручного отслеживания зависимостей.
G>>Это зависит от структуры программы. В моем случае все зависимости явные.
C>Значит оно примитивное.

Ты смешен.


C>>>4) Мешанины UDF, SP и прочих "радостей".
G>>Которые улучшают производительность и уменьшают нагрузку на сеть.
C>Твоя архитектура вся уменьшает производительность и увеличивает нагрузку на сеть.
Слив засчитан

C>>>5) Зависимость от конкретной БД.
G>>Какой ужас...
C>Да.
Ниче что большинство приложений работаю на конкретной БД.
Независимость от БД имеет смысл для решений, разворачиваемых на аренгдуемых хостинг-площадках.

C>>>6) Не будет работать на модеме.
G>> Будет лучше чекм твой вариант
G>>Короче не выдумывай небылицы.
C>Ты всё более неадекватен.

C>Таки предложи как сделать лучше чем моё решение. Критерии я написал выше (6 пунктов). Ждёмс....
Да я уже предложил. Причем то что я предложил уже работает в вебе (и хорошо работает).
А ты только смог выдумать какие-то недостатки которых реально нет.

C>Вот такие вот элегантные L/ORM.
Самое смешное, что задача которую ты решаешь фактически является репликацией данных со сложными условиями.
А эта задача прекрасно решается и без ORM

C>>>Ничуть. Вообще, GMail работает ровно так же, как и мой код. С той лишь разницей, что они вместо H/ORM используют какое-то своё кластерное хранилище.
G>>С чего ты взял? Исходники видел?
C>Нет. Презентации о его архитектуре.
Где можно глянуть ?

Здравствуйте, SHEMA, Вы писали:

SHE>Вот такие интересности ждут Вас при выборе Silverlight-a в качестве базовой технологии для front-end-а enterprise level приложения (back-office-а и т.д.):
Судя по списку "интерестностей" знакомство с сильверлайтом ограничилось туториалом Иначе список был бы другим. А так — мелочевка вперемешку с непониманием, чем вебстраница отличается от сильверлайт приложения.

Здравствуйте, Dog, Вы писали:

G>>>С чего ты взял? Исходники видел?
C>>Нет. Презентации о его архитектуре.
Dog>Где можно глянуть ?
Частично отсюда: http://code.google.com/p/gmail-greasemonkey/wiki/GmailGreasemonkey10API

Ещё здесь было, AFAIR: http://www.youtube.com/watch?v=cQyha30nm6k

Здравствуйте, olegkr, Вы писали:

O>Судя по списку "интерестностей" знакомство с сильверлайтом ограничилось туториалом Иначе список был бы другим. А так — мелочевка вперемешку с непониманием, чем вебстраница отличается от сильверлайт приложения.
колкое замечание, но ничего по делу

Здравствуйте, SHEMA, Вы писали:

SHE>но ничего по делу
Могу еще раз пройтись по пунктам, если есть желание.

SHE>Мало того что дизайнер примитивный (и если пользуетесь Expression Blend, то ето переодическое переключение окон тормозит и достает), так он еще и откровенно глючит
Это да. Expression Blend — полное Г, тормозит, глючит, плюс идиотский размытый WPF интерфейс в могильной теме, которая режет глаз. Плюс к этому интерфейс интуитивно непонятный, что бы найти что-то надо перерыть полмануала. В конце-концов я заметил, что я стал больше полагаться на автокомплит (который тоже сделан через задницу) и подумал — а нафига мне этот бленд?
С тех пор пишу ручками и радуюсь. Впрочем точно такая же ситуация и с html — пишем ручками, если нужен хороший результат. HTML — XAML 0:0

SHE>Забудьте про изменения "на лету", как в ASP.NET. Мелочь?
Мелочь, конечно, но неприятно. Согласен.

SHE>- контролы контролы контролы... Стандартных не хватает. Сторонние — глючат!!! Работал с Telerik, DevExpress — просто не верится, что такие уважаемые компании выкидывают на рынок такое <здесь нехорошее слово>.
Я работаю с Инфрагистик, потому, что стандартный и девэкспрессовский грид, мягко говоря, не функциональны. Проблемы есть, но только с RIA — не умеет работать с домайн контролом, не может забиндиться к риа коллекция в режиме редактирования и т.п. Винить инфрагистик сложно, РИА еше не в релизе, а превью вышло только летом.
Больше глюков пока не нашел.

SHE>- библиотеки. Иногда ето больно
Бывает, но обходится.

SHE>- нет XML/XSLT (есть Linq To Xml — пользуйтесь)
XmlReader/XmlWriter вроде тоже есть

SHE>- проблемно с линками (открытие интернет ресурса в текущем или новом окне — ето придется продумавать SL программисту)
Мелочь

SHE> и URL mapping-ом (SL3 предлагает solution, правда примитивный но какой никакой)
А с ним-то какие проблемы?

SHE>- проблемно с экспортом данных вообще
Никаких проблем не обнаружил.

SHE> + Copy/Paste любого контента в любое приложение — без проблем, с сохранением стилей или без
SHE> + Сохранить на диск — в виде HTML, TXT, MHT (веб архив, со всеми картинками) — без проблем
SHE> + Export таблиц — прямо в Excel (из IE, если установлен Office)
Смешно. Попробуй проделать те же самые операции с винвордовским меню. Не получается? Ах да! Не нужно же это. А почему? А потому, что копи-пасте и экспорт реализованы самим винвордом. И сделаны эти операции намного лучше, чем тот же экспорт html и потом попытка что-то с ним сделать.
Если немного поменять свое ASP.NET-ое мышление и воспринимать Silverlight application именно, как application, а не web page, то проблем станет ноль. Всего то и нужно сделать нормальный интерфейс, который все это умеет. Который позволяет экспортить и копи-пастить только нужные данные, без разметки. Знаешь как бесят все эти вебаппликухи, которые полагаются на то, что юзер все будет делать через стандартные механизмы, как задалбывает выделять строчку в таблице, когда выделение постоянно перескакивает на какой-нить логотип или заголовок, как потом в винворд влезают куски разметки? Нечего нам тут тащить в сильверлайт изначально ущербные практики!
И не надо мне говорить про эксель. В инфрагистике есть замечательные компоненты для работы с экселевскими файлами.

SHE>Пользователю надо комфортно работать с данными.
См. выше.

SHE>Можно ли как-то подружить SL с HTML? да, как-то.
Понятия не имею зачем это нужно в корпоративных приложениях. Видимо для того что бы плодить гибридных уродцев. Тем не менее все для этого есть.

SHE>Любой unhandled exception приводит к crash-у всего приложения.
Ну да. Видимо придется позабыть о жабаскриптной практике забивать на все и грамотно работать с exceptions.

SHE>Там где для html-я надо просто нажать F5, в SL ето тот же F5 только с перезагрузкой всей аппликухи.
А если сделать кнопочку Релоад, то перезагрузится только то, что ты сам захочешь.

SHE>А интеграция с серверными решениями (тот же reporting) ето как правило геморрой тот еще.
С репортингом не сталкивался, но с сервер-сайдом интеграция отличная.

SHE>Вообщем я для себя сделал выводы насчет пригодности SL для написания бизнес приложений.
Я тоже сделал. Наконец-то можно забыть, как о страшном сне, эту жуткую помесь ASP.NET, AJAX, HTML & JScript и писать нормальные корпоративные приложения на SL. Еще очень сильно надеюсь, что часть указанных здесь пунктов заставят девелоперов писать нормальный UI, поменьше полагаясь на стандартно-ущербный от браузера.

Здравствуйте, SHEMA, Вы писали:

SHE>Ну выше yorick назвал главную причину: современный WEB2 ето букет из технологий и языков программирования, помноженный на количество версий/спецификаций/стандартов + особенности реализаций броузеров. Во всем етом надо шарить, изучать приемы / подходы / рецепты / инструменты — вообщем нудно и так сразу не поедешь, возникает естественное желание чиста взять спортивный супер-кар от Microsoft в лице Silverlight-а и ай-да педаль газа под коврик Тока пока на проверку оказывается суперкар по песку не едет, кондиционер работает в одном режиме да и вообще как долго и куда на нем приедешь решает сама Microsoft А так в принципе покататься рекомендую — ето местами захватывающе и действительно на SL можно делать такие вещи, что waauuuu


Соглсен. Используем сейчас ESRI Silverlight API — просто фантастика какая-то!!!

Здравствуйте, olegkr, Вы писали:

SHE>>но ничего по делу
O>Могу еще раз пройтись по пунктам, если есть желание.
Конечно есть, на то здесь и форум

O>С тех пор пишу ручками и радуюсь. Впрочем точно такая же ситуация и с html — пишем ручками, если нужен хороший результат. HTML — XAML 0:0
По крайней мере с HTML легче посмотреть результат (см. пункт ниже)

SHE>>Забудьте про изменения "на лету", как в ASP.NET. Мелочь?
O>Мелочь, конечно, но неприятно. Согласен.
угу

O>Я работаю с Инфрагистик, потому, что стандартный и девэкспрессовский грид, мягко говоря, не функциональны. (...)
O>O>Больше глюков пока не нашел.
Ну у них и прайс-лист блин, полторы штуки баксов за средненький комплект. Плюс наверняка те кто покупал для SL2 теперь еще выкладываются за апгрейд до SL3, по крайней мере из моего опыта приложение на SL2, с использованием Telerik под SL3 ооочень криво пашет. С ASP.NET=>ASP.NET2=>ASP.NET3.5 такого не было. Ну и оно надо такие сюрпризы?

А как тебе сильверлайт биндинг вообще, классы клепать не надоело? Конвертеры, в которые нельзя забиндить параметры (потому что майкрософт считает ето неправильным архитектурным решением). Скажи честно скока их у тебя их уже в проекте в папке Converters? А невозможность забиндить на анонимные типы — оборачивать любой селект LINQ-а отдельным классом — даже в ASP.NET таких ограничений нет... Может я че не так делаю, просвяти.

SHE>>- библиотеки. Иногда ето больно
O>Бывает, но обходится.
Как? Советуешь выкладываться по полторы штуки баксов? то что для web-a валом валяется, в SL экзотика.
Причем для web-a я могу прикрутить ето в любом виде — как activeX, сервис или вообще cgi-шка. И чихать хотел на все SL песочницы.

SHE>>- нет XML/XSLT (есть Linq To Xml — пользуйтесь)
O>XmlReader/XmlWriter вроде тоже есть
Имел ввиду именно связку XML/XSLT. Часто приходится работать с данными в виде XML.
ОК, допустим забили на XSLT, парсим все ручками и генерим на выходе XAML. Ты пробовал привязать сгенеренный XAML к стилям приложения? попробуй и расскажи как. В asp.net ето простой инклуд css import.

SHE>>- проблемно с линками (открытие интернет ресурса в текущем или новом окне — ето придется продумавать SL программисту)
O>Мелочь
угу, а мне удобно этим пользоваться, не зря даже IE сделали multi-tab-ным.

SHE>> и URL mapping-ом (SL3 предлагает solution, правда примитивный но какой никакой)
O>А с ним-то какие проблемы?
Проблемы с сохранением прямого линка на какой-нибудь ресурс(читай страницу) приложения.

SHE>> + Copy/Paste любого контента в любое приложение — без проблем, с сохранением стилей или без
SHE>> + Сохранить на диск — в виде HTML, TXT, MHT (веб архив, со всеми картинками) — без проблем
SHE>> + Export таблиц — прямо в Excel (из IE, если установлен Office)
O>Смешно. (...)
O>Всего то и нужно сделать нормальный интерфейс, который все это умеет.
Ну так кто спорит — всего то.

SHE>>Любой unhandled exception приводит к crash-у всего приложения.
O>Ну да. Видимо придется позабыть о жабаскриптной практике забивать на все и грамотно работать с exceptions.
Да уж.
Если у тебя на web страничке отсутствует картинка — ето просто пустое место.
SL же падает с громким шумом.

SHE>>А интеграция с серверными решениями (тот же reporting) ето как правило геморрой тот еще.
O>С репортингом не сталкивался, но с сервер-сайдом интеграция отличная.
Поделись опытом. SL+WCF? Етот дебильный async-call, так что при чуть более сложной бизнес логике имеем кучу вложенных делегатов — красотаааа

SHE>>Вообщем я для себя сделал выводы насчет пригодности SL для написания бизнес приложений.
O>Я тоже сделал. Наконец-то можно забыть, как о страшном сне, эту жуткую помесь ASP.NET, AJAX, HTML & JScript и писать нормальные корпоративные приложения на SL. Еще очень сильно надеюсь, что часть указанных здесь пунктов заставят девелоперов писать нормальный UI, поменьше полагаясь на стандартно-ущербный от браузера.
А я повременю, пока он доростет до GoldLight и полностью меня устроит. Возможно к тому времени о его предке silverlight-е тоже давно забудят Во всяком случае в долгосрочной перспективе для проекта на 2-5 лет уж точно выбор будет не в пользу SL — не улыбается мне каждые год два переписывать все под новую версию.
А от жуткой смеси AJAX, HTML & JScript разработки идут и в других направлениях — посмотри GWT подход — там весь страшный и ужасный AJAX компилируется и генериться из JAVA кода.

Здравствуйте, SHEMA, Вы писали:

SHE>Ну у них и прайс-лист блин, полторы штуки баксов за средненький комплект.
За топовый с priority support. Без него штука баксов. Включает в себя ASP.NET & Silverlight. Так что, хоть на сильверлайте, хоть без него, ценник один.

SHE>Плюс наверняка те кто покупал для SL2 теперь еще выкладываются за апгрейд до SL3
У них ничего не было под SL2. Только-только этим летом выпустили первый релиз. У меня вообще сложилось ощущение, что до SL3 все было баловством, а только сейчас, летом, SL стартовал более-менее серьезно. И сам сильверлайт доклепали до удобоваримого состояния, и RIA вышла, и контролы поперли. Думаю к зиме ситуация кардинально улучшится, т.к. народ серьезно взялся за сильверлайт.

SHE>А как тебе сильверлайт биндинг вообще, классы клепать не надоело?
Байндинг весело. Пока не посидел и не угробил вечер на чтение статей в MSDN мозги плыли. Потом все встало на свои места и оно понравилось, действительно можно сделать дофига без извратов в коде.

SHE>Конвертеры, в которые нельзя забиндить параметры (потому что майкрософт считает ето неправильным архитектурным решением).
Не оно? Одна из первых ссылок в гугле.
http://betaforums.silverlight.net/forums/p/124198/280478.aspx

<Image Source="{Binding Converter={StaticResource imgConv}, ConverterParameter="{Binding Sex}" Stretch="Fill"  />

SHE>Скажи честно скока их у тебя их уже в проекте в папке Converters?
Хватает. В основном enums. Как бы их всех в один конвертер свести...

SHE>то что для web-a валом валяется, в SL экзотика.
Это понятно. SL молод пока ищщо. (см. выше) Не успели кучу контролов халявных наклепать, но процесс пошел.

SHE>Причем для web-a я могу прикрутить ето в любом виде — как activeX, сервис или вообще cgi-шка. И чихать хотел на все SL песочницы.
Тут не совсем понял, ты смешал в одном предложении client & server side.

SHE>Ты пробовал привязать сгенеренный XAML к стилям приложения?
Нет не пробовал.

SHE>угу, а мне удобно этим пользоваться, не зря даже IE сделали multi-tab-ным.
Тут без примеров сложно что-то сказать. Вероятнее всего ты проектируешь UI как привык, в веб-стиле.

SHE>Проблемы с сохранением прямого линка на какой-нибудь ресурс(читай страницу) приложения.
Тут-то какие проблемы? Есть URL, по которому маппер тебя пошлет на нужную вьюху, и если надо с параметрами, которые вьюхе будут переданы. В чем проблема потом этот линк сохранить?

SHE>Если у тебя на web страничке отсутствует картинка — ето просто пустое место.
SHE>SL же падает с громким шумом.
Падает. Если не обрабатывать исключения, то много чего падает. Согласен, веб подход тут не применим.

SHE>Поделись опытом. SL+WCF? Етот дебильный async-call, так что при чуть более сложной бизнес логике имеем кучу вложенных делегатов — красотаааа
SL+RIA. Красотаааа! Рекомендую попробовать, хотя инфрагистиковский грид его поддерживает пока с трудом. Обещают в ближайшее время исправится, но я думаю раньше ноября сервис релиза мы так и не дождемся.

Здравствуйте, IT, Вы писали:

IT>Единственная проблема — уровень подготовки разработчиков.

в конторе где я работаю последние 5 лет мы сталкивались (на самом деле расшибались) именно об эту проблему не менее трех раз. Пробовали разные подходы в том числе используя разные фреймворки — проблемы одни и те же. Тяжело\долго обучить ресурс со стороны конкретному фремевейрку и стилю, если так можно выразится, его использования.
Как это ни странно, но из десятков проектов в которых я принимал участие одним из самых успешных был проект в котором использовалась POCO модель данных и комбинировались ADO.NET (более старый код времен сотворения .NET 1.1) и BLToolkit для работы с базой данных. Проект до сих пор расширяется новой функциональностью без особых проблем. Недавно передавали проект другой группе разработчиков для дальнейшего сопровождения — возникавшие по ходу вопросы в большинстве своем не касались DAL\ORM.

В новом проекте (несколько месяцев, совершенно другая предметная область) пришел новый ресурс с хорошим знанием NHibernate. Решили попробовать NHibernate еще раз (первый раз обламались на нем года 3 назад). И началось 'притягивание' модели данных под нужды фреймворка. Модель получилась гораздо более правильная с точки зрения DDD чем в упомянутом ранее проекте, но ее использование другими разработчиками более проблематично, так как налагает определенные требования к знанию\поддержанию состояния модели. Плюс разработчик должен понимать что конкретное design решение в модели данных было принято не потому, что так было хорошо, а потому что ТАК НАДО для работы фреймворка. ИМХО именно это часто вызывает самые серьезных затруднения.

В конечном итоге мораль сей басни такова — IT прав в том, что чем меньше требований инструмент предъявляет разработчику, тем больше вероятность что он будет использован, и, как ни странно, использован правильно...

ИМХО успешность использования фреймворка командой разработчиков может быть определена формулой, схожей с определением счастливой семейной пары, где каждый старается больше дать, чем получить взамен, и при этом не выдвигает идиотских требований\условий
Ну, и личные симпатии к отдельно взятому фреймворку при соблюдении выше помянутого требования, конечно, тоже никто не отменял...