AntonariyДля xsl интеллисенс есть, для html он нафиг не нужен.
Это не интеллисенс, а гумно на лопате. Сравни с интеллисенсом мвц, когда тебе доступны всё атрибуты модели в предоставлении, когда тебе доступен весь .нет в модели. Это называется интеллисенс.

AntonariyЧеловечески читаемого html нет как раз в мвц. Но это наверное дело вкуса.

В мвц есть человечески читаемый язык, а не те огрызки тегов, которые в xslt. Во-вторых в мвц или вебформс никто не запрещает писать человеческий хтмл. В любом случае это читабельно и понятно для восприятия.

AntonariyСтудия тут же выкатит ошибку. Чтобы страница завалилась, нужно вообще нихрена не обращать внимания на сообщения студии.

Я тебе о ошибках на этапе компиляции. xslt может прийти из тфс битый и никто ошибки не заметит, пока не отработает шаблон. И чаще всего такие ошибки идут прямиком на продакшен.
В случае же мвц или винформс большинство ошибок не пропустит студия.

AntonariyКаком еще клиенте? Клиент получает готовый html. И рендерит его лишь в графическом смысле слова.
На обычном клиенте, браузер называется. Асп.нет рендерит, это и уходит на клиента.

orunbekМожет быть действительно xml+xslt это старье, но возможности xslt-шаблонов (условное конструкции, циклы, проверка последних строк, группировка) меня устраивают и позволяют создавать простые шаблоны для формирования сложных табличных данных.


Всё это делается родными средствами вебформс без каких-либо костылей и подпорок. Причем это работает быстро и проблем не возникает.

orunbekМСУ...
Еще раз говорю - это задача сайта, а не бд или сервиса. Сервис должен возвращать DTO объект (или коллекцию их), а задача веб-формс всё это отрендерить через родной движок
...

А если сервер БД будет возвращать набор xml, а web-сервер будет преобразовывать xml в html-табличку через xslt будет это "архитектурно" правильно? так сказать в стиле MVC?
И это решение от текущего будет отличаться только тем, что трансформацией занимается Web-сервер а не сервер БД, и все.
Но в любом случае задача преобразования xml-данных в html'таблицы на стороне клиента остается.
Забудь про xml. Не нужно его впихивать в каждую щель. Он оправдан только там, где действительно это надо. В твоем случае твоя архитектура - помойка.

orunbekP.S. Это я не для оправдывания, а хочу узнать насколько xslt-трансформация потеряла свою актуальность, и если это так, то "менять курс" в следующих проектах ;-)
Потеряла еще давно, как только появился асп.нет. А когда вышел мвц, то и подавно.
Отголоски классического асп, которым место на помойке, а не в .нет решениях.

orunbekданный вариант формирования данных я использую в первую очередь из-за скорости и гибкости при формировании html-таблиц или данных.
А почему тогда жалуешься, что всё тормозит?
orunbekКонечно, если есть более нативный, быстрый и гибкий для ASP.NET (3.5 или 4ой версии) способ формирования html из данных sql сервера или xml-данных, то я с удовольствием опробовал бы этот способ, отдавая "дань моде" :-)
Десятый раз говорю, забудь про xml. Ты на нем помешался

AntonariyМСУпропущено...

На обычном клиенте, браузер называется. Асп.нет рендерит, это и уходит на клиента."Рендерит, это и уходит на клиента" это не тоже самое, что "рендерит тебе на клиенте".
Я обобщенно сказал, если требуется разжевывать, то ок.

orunbekМСУ,

ёклмн, кто жалуется что тормозит?
Я ищу способы дополнительной оптимизации, а xml просматриваю только "в свете" трансформации в html через xslt и уменьшения трафика от Web-сервиса к клиенту.
А варианты рендеринга данных из базы без использования серверных контролов наподобие GridView?
На стороне web-сервиса WCF к примеру?
Не понимаю, зачем оптимизировать то, что замечательно работает?
А если ты хочешь трансформацию делать на клиенте, это еще больше трафика будет.
На стороне веб сервиса рендерить html идиотизм. Почему ты так боишься заниматься этим на сайте, собственно, где рендерингу и место?

Мля, люди. Ваши убитые жизнью архитектуры не видывали базы от сотен гигабайт и выше, а так же нагрузку в пиках при минимум 5 тыс. пользователей в момент времени. За ваши xml из хранимых процедур дба минимум яйца отрежет, за xml + xslt сайт набок сляжет. Безумцам классического асп нужно не подпорки переносить на новые платформы, а заново перерабатывать механизм в соответствие с новыми технологиями и правилами.

Если тебе нужен полный контроль разметки (особенно важно для мобильных клиентов) и полное разделение логики и представления - мвц, строго. Если этим можно пренебречь, оставайся на вебформс.

orunbekВ данный момент полугодичная база весит 245gb, число активных пользователей в среднем 2000-2500 пока что.
Неплохо. И что, нет вообще проблем с производительностью, всё летает? Хоть убей, не верю :)

orunbekНа завтра подготовлю пример по работе с данными MS SQL
вариант вывода данных через XML+XSLT полностью на стороне SQL-сервера
вариант вывода данных через XML+XSLT, на стороне SQL-сервера получение xml-данных, на стороне Web-сервера траснформация через XSLT
Думаю, пример построчного вывода делать нету смысла, так как он во всех отношениях проигрывает
Оба варианта плохие. Самый правильный - получение чистых данных из сиквел сервера, на стороне веб-сервера - преобразование чистых данных в xml и трансформация через xslt.
А вообще и этот вариант ужасен, ибо мвц :)