Web Service 的一个问题

bffbffbff

原帖由 linkspeed 于 2011-5-30 17:24 发表
xslt巨慢。。

这个好像。。。确实不快

乱码

原帖由 bffbffbff 于 2011-5-30 17:15 发表


白条2！ 老大就是牛

我们最近用xslt的主要目的是因为stored proc生成的xml有时候会有一些限制（比如同一级的不同column出来的element名字不能重，还有一些更灵活的格式变化等等），发现结合xslt一起用可以在数据已经拿出来的情况下对格式变化方面有很不错的灵活性。
谈不上多喜欢，只是发现用了以后觉得功能比自己预想的要大和灵活许多。

恩，用xslt对数据加工一下也不错，不过linq to xml也应该可以做到（我没做过）．

dalaohu

这个没办法的， 实际情况中，这xml可能是银行来的，里面甚至是cobol format。必须要先大量处理，才可读。 到最后才map 到poco。

当然简单情况下，是可以直接map 到poco。 但这种情况太理想状态了。而且比较脆弱了，xml以后可能会变，poco是code gen来的，基本上是绑定在table上的。

典

XSLT一般情况下 [特指客户端情况]，其实不应该很慢的，除非 XML文件特大。我们的文件有1~4M大的，用XSLT处理不觉得慢，可能生成一个复杂页面也就1-3秒左右，跟具体情况有关。
XSLT Performance同程序员很有关，经验不足的程序员写出来的可能会很慢，我碰到好多次这种情况了

[ 本帖最后由 典 于 2011-5-30 20:11 编辑 ]

o2h2o

原帖由 linkspeed 于 2011-5-30 17:23 发表
2. convert xml to strongly typed using the typed xsd.
some dudes above says using POCO directly, it's a wrong approach. POCO belongs to data domain, and here we're in business domains.  and the raw xm ...

我觉得不需要 poco
直接用转换的 xsd 的 class
反正本来的数据库也不是为这个xml 设计的，需要兼容化之后在存入
visual studio 的 xsd to object 的工具不好用，太原始，不支持复杂一点的xml xsd

需要看看 xsd 转换的 class 可以不可以 读入一个xml 直接转换成一个 object 估计就差不多了

以前碰到一个 40多xml 的 project
没 schema
我就是全用linq to xml 弄的
也还凑合
这个文件太多了，而且有schema，所以想问问什么方式是最好的

[ 本帖最后由 o2h2o 于 2011-5-30 19:50 编辑 ]

showen

XSLT在客户端邦定xml的数据， 要比用 js + template邦定数据要快很多

服务器端xslt觉得太慢了，一般不考虑。

linkspeed

>我觉得不需要 poco, 直接用转换的 xsd 的 class

就是这个意思，但是poco需要加点代码才可以用在EF上面。


》XSLT在客户端邦定xml的数据， 要比用 js + template邦定数据要快很多

哪个网站是这样开发的？
虽然很早浏览器就支持xslt了，我还没见过输出xslt+xml到browser得网站。

乱码

原帖由 linkspeed 于 2011-5-30 20:33 发表
>我觉得不需要 poco, 直接用转换的 xsd 的 class

就是这个意思，但是poco需要加点代码才可以用在EF上面。


》XSLT在客户端邦定xml的数据， 要比用 js + template邦定数据要快很多

哪个网站是这样开发的？
虽然很早浏览器就支持xslt了，我还没见过输出xslt+xml到browser得网站。

u may start from here.

http://us.blizzard.com/store/index.xml

o2h2o

原帖由 linkspeed 于 2011-5-30 20:33 发表
>我觉得不需要 poco, 直接用转换的 xsd 的 class

就是这个意思，但是poco需要加点代码才可以用在EF上面。


》XSLT在客户端邦定xml的数据， 要比用 js + template邦定数据要快很多

哪个网站是这样开发的？
虽然很早浏览器就支持xslt了，我还没见过输出xslt+xml到browser得网站。

unsw 的学生系统也是 xml +xslt的

典

xslt+xml（客户端生成页面）我们公司一个内部系统用着

showen

恩 刚才我还在找blizzard来着， 记得去年看他们有的页面就是一个xml，挺NB的

showen

xslt就是语句上的learning curve比较大，再一个是跨浏览器兼容的问题，不然做前台还是很值得考虑的

公司内部开发，很容易统一浏览器，所以xslt是个不错的选择.

乱码

原帖由 showen 于 2011-5-30 21:09 发表
恩 刚才我还在找blizzard来着， 记得去年看他们有的页面就是一个xml，挺NB的

嗯，暴雪是世界上唯一一个大规模用client side xlst的website了，不过性能的确不错。

再重新作谁也不敢说他们还继续沿用这个模式。

dalaohu

原帖由 o2h2o 于 2011-5-30 19:46 发表


我觉得不需要 poco
直接用转换的 xsd 的 class
反正本来的数据库也不是为这个xml 设计的，需要兼容化之后在存入
visual studio 的 xsd to object 的工具不好用，太原始，不支持复杂一点的xml xsd

需要看看 xsd 转换的 c ...

我说的就是不要用poco， poco是EF data domain 的。

你用 xsd.exe command line 吧40个xsd 都转成typed吧。
参见 http://msdn.microsoft.com/en-us/library/x6c1kb0s(v=vs.80).aspx

bffbffbff

原帖由 典 于 2011-5-30 19:20 发表
XSLT一般情况下 [特指客户端情况]，其实不应该很慢的，除非 XML文件特大。我们的文件有1~4M大的，用XSLT处理不觉得慢，可能生成一个复杂页面也就1-3秒左右，跟具体情况有关。
XSLT Performance同程序员很有关，经验不足的程序员写出来的可能会很慢，我碰到好多次这种情况了

恩，估计我有的地方写的不好，一个1m左右的xml的差不多花2s左右

iceman

可以试试www.smooks.org

dalaohu

我上个项目里，我专门做个性能测试，服务端xslt处理大文件是性能比较低.

但这个扯远了，你现在有机会用xslt那很好，不少地方还是挺看重这个的，对你的简历是个卖点。

xslt垮平台，不局限于。net，这点就够了。其他也都是扯淡。

乱码

原帖由 bffbffbff 于 2011-5-30 21:16 发表


恩，估计我有的地方写的不好，一个1m左右的xml的差不多花2s左右

client side 生成html的engine的确要精挑细选，不然就用server side tech生成tailor made的html，让browser直接render出来。

我们的new relic (http://newrelic.com/)数据显示，server side耗用的时间占总时间的1/5左右，其他的时间全在网络传输和page rendering上面。

其中我们能控制的就是用干净简洁的html,js位置别乱放就成了。

browser这方面能力差别也挺大，IE9的确很厉害，都略胜chrome，其他的brower从performance来讲也就是摆设，ff4可能被它的那些addin拖累了，表现差强人意.

bffbffbff

原帖由 dalaohu 于 2011-5-30 21:24 发表
我上个项目里，我专门做个性能测试，服务端xslt处理大文件是性能比较低.

但这个扯远了，你现在有机会用xslt那很好，不少地方还是挺看重这个的，对你的简历是个卖点。

xslt垮平台，不局限于。net，这点就够了。其他也都是扯淡。

恩，过几天就等做好了开始用的时候正式测试了看效果了，感觉多用用xslt的东西对xpath的理解还是很有帮助的。

o2h2o

原帖由 dalaohu 于 2011-5-30 21:16 发表


我说的就是不要用poco， poco是EF data domain 的。

你用 xsd.exe command line 吧40个xsd 都转成typed吧。
参见 http://msdn.microsoft.com/en-us/library/x6c1kb0s(v=vs.80).aspx

xsd 是第一个不行的
他说他只支持simple type
我给的 xsd 太复杂

dalaohu

那是因为xml 只支持simple type, 跟xsd又没关系。
simple type 是所谓的 int, string, date...之类。

跟你schema的复杂程度无关。  xsd.exe 不行的话，那世界上就没其他工具行了。

典

原帖由 bffbffbff 于 2011-5-30 21:34 发表


恩，过几天就等做好了开始用的时候正式测试了看效果了，感觉多用用xslt的东西对xpath的理解还是很有帮助的。

你们用什么Parser了？

linkspeed

>http://us.blizzard.com/store/index.xml

这个哪里是xml+xslt的？chrome里面用developertool看，那个index.xml就是html,
已经转化好的了。

xsd的复杂type就是新element了，不过xsd转出来的代码需要手工处理一下。
有个双重数组问题。

dalaohu

我以前玩wow时，blizzard 的确是xml 的。最近改版了，就放弃xml了。

xsd的composit type 包含的也都是simple type. 所以没有复杂type这一说的。
composite type 会被转化成 class, 里面的properties 都是simple type.

bffbffbff

原帖由 典 于 2011-5-30 21:44 发表

你们用什么Parser了？

你是问xml还是xslt的parser？
production的已用的这方面的东西我不太了解， 我最近几周xml,xslt测试一个有经验的同事让我用一个好像叫ixedit的东东，可以读xml文件，process xslt， 然后生成的xml，还可以指定xsd文件来validate生成的结果。
你是这方面专家了，有啥建议？ 还有你们那用啥东西？ 我也好学习学习？

典

原帖由 bffbffbff 于 2011-5-30 22:19 发表


你是问xml还是xslt的parser？
production的已用的这方面的东西我不太了解， 我最近几周xml,xslt测试一个有经验的同事让我用一个好像叫ixedit的东东，可以读xml文件，process xslt， 然后生成的xml，还可以指定xsd文件来validate生成的结果。
你是这方面专家了，有啥建议？ 还有你们那用啥东西？ 我也好学习学习？

大汗，我们用得很土, msxml那一套 ，只适合企业内部网，浏览器单一的情况

典

原帖由 dalaohu 于 2011-5-30 22:12 发表
我以前玩wow时，blizzard 的确是xml 的。最近改版了，就放弃xml了。

.

我看blizzard的下来的文件中有个javascript文件叫sarissa.js, 显然是XSLT的东西，但是不知道它怎么用的，或者根本就没用？

3laugh

Save the xml into the db first, the parse them later.

You save the xml, and xml will save you if anything goes wrong with the parser, the vendor, the procs , whatever...

o2h2o

原帖由 dalaohu 于 2011-5-30 21:42 发表
那是因为xml 只支持simple type, 跟xsd又没关系。
simple type 是所谓的 int, string, date...之类。

跟你schema的复杂程度无关。  xsd.exe 不行的话，那世界上就没其他工具行了。

xsd.exe output
------------------
Error: There was an error processing 'XXXOTA_XXXXX.xsd'.
  - Error generating code for DataSet ''.
  - Unable to convert input xml file content to a DataSet. DataSet doesn't suppo
rt 'union' or 'list' as simpleType.
  - DataSet doesn't support 'union' or 'list' as simpleType.
--------------
用了 stackoverflow 里面推荐的 xsd2code
完美 转换
--
呵呵 你对xsd 的评价好像比微软对他都要高一点

[ 本帖最后由 o2h2o 于 2011-5-31 09:54 编辑 ]

dalaohu

成功了就好，我以为大多第三方工具都是基于xsd.exe 得。　所以说IT是门实践科学。

你能不能吧那个xsd上传一下？　我很想试一下。　union，　list应该被转成class　才对。。。