Приветствую всех.
В данный момент есть Web-проект (Web-клиент к базе) в котором очень часто выводятся различные табличные данные из базы данных.
Web-сервер IIS 7.5, сайт на ASP.NET+jQuery
База данных на MS SQL Server 2008 R2.
В данный момент данные из базы выводятся в Xml и в самом SQL сервере же транслируются в html-таблицу путем XSLT-шаблона.
При этом применяются различные свойства (классы) для тэгов td, tr в зависимости от значений данных в базе, т.е. активно используются инструкции if, case в XSLT-шаблонах. Также генерация различных handler'ов на события click в ячейки или в тэги th.

В данный момент ищу способ перенести преобразование xml-данных в таблицу на стороне клиента.
Возможно, средствами jQuery, но при этом было бы хорошо использовать xslt-шаблоны, без глюков на современных браузерах, буду использоватся если не самые последние браузеры, то хотя бы релизы последних 2х лет.
Цель, уменьшить нагрузку на сервере переключив трансофрмацию на клиентской стороне, и уменьшить трафик, так как передача xml-данных с небольшими атрибутами для кастомизации отображения в любом случае меньше html-данных.
Понимаю что выигрыш в килобайтах не большой может быть, но на счету дорог каждый байт.
Так как большая часть клиентов используют дорогой тариф мобильного интернета, и отдаленность клиентов тоже влияет на скорость передачи данных.

Может быть кто-то уже переходил с решения xml+xslt на более эффективный способ трансформации xml-данных в html?
Читал про yate yandex'а, но он привязан к json и в данный момент мало документирован.
Из-за этого хотел услышать мнения про эффективные (по скорости и по возможностям кастомизации) преобразования xml-данных в html-таблицу.

Спасибо за внимание и жду советов от "бывалых" ;-)

Т.е. предлагаете оставить все как есть?
А передача xml с трансформацией через xslt на стороне клиента, это "море браузеров с кучей подводных камней"?
И в конечном счете больше проигрыша чем выигрыша?

МСУ,

За XML+XSLT на стороне клиента? или на стороне сервера?
Или вообще за XML+XSLT?

МСУorunbekМСУ,

За XML+XSLT на стороне клиента? или на стороне сервера?
Или вообще за XML+XSLT?
Я про xml + xslt = html.

Наследие прошлого, когда хотели полностью отделить логику от представления. Сейчас есть asp.net mvc, его и используем.
А грабли типа xslt - большой жирный гроздь в производительность, в поддержку, в рефакторинг и в сопровождение. Скорость разработки шаблона в разы выше, чем разработка на родных движках webforms / mvc. Нужна правильная архитектура и быстрое качественное решение? Юзай полноценные фреймворки, а это гумно на лопате - удел кривомыслящих архитекторов с идиотской идеей универсализировать мир.

В моем проекте xml+xlst предназначено не для построения всего сайта или шаблона для всего сайта, а для вывода готового html из базы данных. К примеру не надо циклично строить таблицу перебирая каждую строку из результатирующего рекордсета, а сразу внутри хранимой процедуры в SQL Server'е, получаю данные в виде XML, которые посредством трансофрмации шаблоном xlst преобразую в html-данные.
Вопрос именно в этом, т.е. в более быстром (чтобы меньше ресурсов сервера уходило, т.е. web-сервис возвращает сразу xml-данные) и экономичном (сами xml-данные "меньше" будут весить чем html-таблица к примеру) способе передачи полученных данных от сервера.

МСУ,

дополню еще, у меня еще не было опыта в использовании MVC-фреймворков, в основном небольшие проекты обращающиеся к БД и возвращающие различные данные.
Есть ли способы в ASP.NET MVC 3ей версии или в 4ой версии, более быстрые варианты преобразования xml-данных в html-таблицу к примеру, ежели связка xml+xslt?

Например, следующий xml



в таблицу вида:



Спасибо

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

МСУorunbekвнутри хранимой процедуры в SQL Server'е, получаю данные в виде XML, которые посредством трансофрмации шаблоном xlst преобразую в html-данные.
Всё запрещено, причем сильно. Архитектора такого решения на свалку.
Не нужно в слой бд закладывать вопросы представления (хтмл) или модели (xml). База данных предназначена для хранения данных и только для этого. Обращение к базе и выдача результата должна быть как можно быстрой. Никаких преобразований в xml средствами базы, только данные, правильно поставленные индексы и всё. После того, как данные попадают на сервер приложений, их в сыром виде конвертируют в модель (представления), которую скармливают самому представлению (через контроллер, если это мвц). Никаких преобразований xml, xslt. Так работают всё нормальные движки, которые рендерят html (webforms, mvc - razor, aspx, ...). Ты же используешь свой наколенный движок рендеринга на основе xslt, да еще и в слой бд прибил xml. Жуть, разумеется весь этот навоз будет нереально тормозить. Особенно на большом кол-ве данных и при большой нагрузке (в т.ч. при пиках) на сайт. Два варианта - переписать этот бред на нормальном движке либо оставить всё как есть и насладиться тормозами. Я бы начал переписывать отдельные части проекта, при наличии ресурсов, конечно.

Понимаю недовольство, особенно в свете решений MVC. Данный проект перекочевал из ASP Classic в ASP.NET, и там и там скорость преобразования данных (recordset'а) в html, скажем так цикличным построением tr, td жутко тормозил, а после переноса решения в xml+xslt все летает, и при оочень больших объемах данных и при больших нагрузках тоже.
Я на этот вариант перешел именно из-за торможения, при цикличном преобразовании данных из базы в html-таблицу на стороне ASP.NET приложения.
Архитектурно, конечно может быть и неправильно, но все работает.
Сопровождать в принципе не сложно, xslt-шаблоны записаны в таблице шаблонов, и при вызове определенной хранимки, данные выдаются в xml (посредством инструкции t-sql FOR XML), и там же преобразуются в html-таблицу путем вызова .NET CLR хранимки трансформации xml через xslt.
Все работает, добавляется новый отчет? Добавляю новый шаблон в таблицу и добавляю формирование отчета в хранимку и указываю какой шаблон использовать и все.
Если есть быстрый и опробованный способ преобразования данных из базы, скажем datareader'а в html таблицу, скиньте линк пожалуйста, для ликбеза

МСУ,

У меня web-forms в связке с jQuery работает, вызывается метод wcf-сервиса, который получает из БД готовый html, который и вставляется в внутренность определенного div'а
Подскажите плз метод трансформации данных sql в WCF-сервисе в таблицу со сложными правилами, т.е. подитожывание, проверка значений и добавление onclick и других event'ов в код таблицы и при этом без потери скорости

для меня желательно не использовать server'ные контролы наподобие GridView, так как они достаточно тяжеловесны
очень много ajax'а и поэтому со стороны web-сервиса должны возвращаться готовые данные

МСУО, да тут и вцф сервис есть
Еще раз говорю - это задача сайта, а не бд или сервиса. Сервис должен возвращать DTO объект (или коллекцию их), а задача веб-формс всё это отрендерить через родной движок. А у тебя сборная солянка какая-то.
Я это полностью понимаю в плане правильной архитектуры, но такой вариант я использовал только для эффективной и быстрой выборки данных. Конечно можно сделать так, чтобы хранимка в сервере БД возвращала просто xml-набор данных, а преобразованием в html-таблицу будет заниматься Web-сервер.
Но даже в этом случае, знаю только один способ быстрого преобразования в html-таблицу из xml.
Цикличная обработка сразу отпадает.
А все перенес в SQL из-за того, что t-sql может очень быстро возвращать набор записей в xml-виде и остается только преобразовать посредством xslt-трансформации и для того, чтобы не хранить xlst-шаблоны локально на сервере, а прям из базы вытаскивать и трансформировать

ПарамонorunbekЯ на этот вариант перешел именно из-за торможения, при цикличном преобразовании данных из базы в html-таблицу на стороне ASP.NET приложения.
Странно все это.
Вы что, всю базу в html выгружаете? А на странички там разбить? )
Нет конечно, просто специфика задачи есть, которая не позволяет использовать постраничное деление данных

МСУorunbekдля меня желательно не использовать server'ные контролы наподобие GridView, так как они достаточно тяжеловесны
очень много ajax'а и поэтому со стороны web-сервиса должны возвращаться готовые данные
Они не тяжеловесны в прямых руках. И уж тем более не тяжеловесней, чем твоя сборная солянка :)
Юзай родной рендерринг вебформс и будет щастье.
В некоторых случаях вообще хватит клиентских контролов. Но упаси боже никаких xml и xslt.
Может быть, но для меня проще использовать "чистый" html с возможностями jquery

ShSergeorunbek,

Возвращайте не ХML, а JSON.
Можно в вэб-приложении (на сишарпе, например) трансформировать XML2JSON, а в браузере - дело техники. Можно ExtJs заюзать, например, или ручками.
В простых наборах данных так и делаю, т.е. WCF-сервис обращается к базе, вызывает хранимку, получает результат и возвращает их в JSON-наборах данных.
Основная проблема в преобразовании табличных данных из базы в html-таблицу

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

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

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

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

При этом скорость обновления данных из БД в html думаю получше будет, в проекте где данные обновляются путем ajax-вызова WCF-сервиса
чем подобное решение
В связке "чистый html"+ajax+wcf (который возвращает готовый html-таблицу, трансформированный из xml-наборов данных посредством xslt)

Ну а вообще, вне сабжа, есть ли проекты, в которых кто-либо до сих пор используются xslt-шаблоны для формирования табличных или иных данных?

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

ShSergeorunbek...Может быть действительно xml+xslt это старье...
Нет, всё нормально. Может быть, не очень удобно для программиста (мне, например XSLT писать лень), а так - всё отлично. Другое дело, что всё-таки хмл - данные, а хтмл - отображение этих данных. Здесь важно почувствовать некоторую разницу. То есть, я в хтмл могу вставить яваскрипты, я могу их и в селект из БД вставить, но - нехорошо мухи с котлетами мешать.
Короче, проблемы имеют только религиозный характер. :)

Понятно, данный вариант формирования данных я использую в первую очередь из-за скорости и гибкости при формировании html-таблиц или данных. Конечно javascript туда "не пихаю", а просто onclick на определенную функцию, в зависимости от определенных значений, ну или различные css-class'ы через тэг xsl:attribute в зависимости от значения исходных данных

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

МСУ,

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

orunbekМСУ,

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

Погуглил, выше уже приводил эту ссылку, нашел пока этот
http://www.aspsnippets.com/Articles/Bind-Dataset-to-ASPNet-GridView-using-jQuery-AJAX.aspx

есть решение которое более "элегентно" и "побыстрее" будет?

Мм.... надо попробовать реализовать тест, смогу без проблем такое сделать
для построчного вывода в ASP.NET и/или XML/XSLT вариант
но не смогу сделать оптимальный вариант рендеринга в html-таблицу в WCF-сервисе в ASP.NET MVC
на третий случай есть у кого желание и время написать простой тест на SELECT? С различными дополнениями в виде дополнения css-class'ов к tr в зависимости от исходных значений?

На завтра подготовлю пример по работе с данными MS SQL
вариант вывода данных через XML+XSLT полностью на стороне SQL-сервера
вариант вывода данных через XML+XSLT, на стороне SQL-сервера получение xml-данных, на стороне Web-сервера траснформация через XSLT
Думаю, пример построчного вывода делать нету смысла, так как он во всех отношениях проигрывает

На пример, представим ту же трансформацию на стороне клиента средствами xml+xslt, xml весит меньше чем конечный html, по крайней в моем случае, а xsl шаблон будет закеширован. Кроме того уменьшается нагрузка на стороне сервера.
Ну как вариант, но как в начале ответили и google "подсказал" о проблемах браузеров, из-за чего ищу другие способы.
Раз тема пошла про MVC что для меня ново, хотел разузнать больше, если по скорости и функционслу больше почему бы на MVC не перейти?

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

В данный момент полугодичная база весит 245gb, число активных пользователей в среднем 2000-2500 пока что.
Есть схожие проекты с такой же технологией работает уже несколько лет и без проблем.

В последнем проекте желательно уменьшить траф между клиентом и сервером и постараться уменьшит нагрузку, так как собираюсь там запустить еще 2 проекта

Dell PowerEdge T610
CPU 2 Xeon, 8 ядер
RAM 32Gb

летает и проблем с производительностью нет, над эти проектом я уже работаю где-то год более-менее нормально эксплуатироваться начал последние 6 месяцев, можете по моим постам проверить, в частности ms sql. Частота вызова трансформации достаточно интенсивная.
Только я не буду доказывать потому что это правда.
И от вас не требую доказательств, лучше давайте подойдем к решению вопроса более конструктивно.
Если есть время, помогите с примером на ASP.NET MVC в связке jquery+wcf с серверным контролом gridview, проверил бы и для себя выводы сделал бы, да и уроком кому нибудь послужил бы.