Приветствую всех.
В данный момент есть 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-шаблоне.