Web Service 的一个问题

o2h2o

需要是这样的,
有几百个xsd, 非常规整的,well formed,只有xsd,没其他的了

需要建立一个 web service (不需要用wcf)
用户 发 xml request,那种xml request 是 前面定义的 xsd 的format

server 端 把 那些xml 变成 数据 存入 数据库
已经有数据库了,里面有其他地方来的数据
需要 重新写代码 merge 起来
例如某个xml字段去某个 db 字段

怎么样实现最好?

例如 把xsd 先map成对象? xsd2code 什么的?

多谢了

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

典

xml 变成 数据 存入 数据库 for what?

One of the options is : save to a xml column:
user_id [ int],
user_requset[xml],
time_stamp[datetime]

o2h2o

原帖由 典 于 2011-5-30 15:42 发表
xml 变成 数据 存入 数据库 for what?

One of the options is : save to a xml column:
user_id [ int],
user_requset[xml],
time_stamp[datetime]

已经有数据库了,里面有其他地方来的数据
需要 重新写代码 merge 起来
例如某个xml字段去某个 db 字段

乱码

强烈建议parse以下，再map到已有的table/column,不要存xml data．

这样的好处

1.节省空间。
2.容易维护,不是每个developer都喜欢xpath。
3.database那边性能好。

believe me, I've learned it in hard way

[ 本帖最后由 乱码 于 2011-5-30 15:50 编辑 ]

典

Ignore me if I mis-understand you

What we did for xml to DB is: just pass the XML to a stored proc,
In the stored proc, merge xml-information to different tables.
We have hundreds of such procs to save XML to DB.

we also have few scenarioes, which only need to keep XML for configuration or log, we use XML columns,

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

bffbffbff

原帖由 乱码 于 2011-5-30 15:48 发表
强烈建议parse以下，存非 xml data．

这样的好处

1.节省空间。
2.容易维护,不是每个developer都喜欢xpath。
3.database那边性能好。

believe me, I've learned it in hard way

等你等完全用熟xpath运用自如了你可能就愿意一切先放起来然后再处理了也说不定 ogay ？

o2h2o

原帖由 乱码 于 2011-5-30 15:48 发表
强烈建议parse以下，存非 xml data．

这样的好处

1.节省空间。
2.容易维护,不是每个developer都喜欢xpath。
3.database那边性能好。

believe me, I've learned it in hard way

那就是把 xsd 先 map 成对象?
用户传上来的 xml 先变成对象
然后save to db ?

btw:
那个 xsd 太多了
真的太多了
又多又长

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

bffbffbff

原帖由 典 于 2011-5-30 15:48 发表
Ignore me if I mis-understand you

What we did for xml to DB is: just pass the XML to a stored proc,
In the stored proc, merge xml-information to different tables.
We have hundreds of such procs to sa ...

我们也做的类似

乱码

原帖由 o2h2o 于 2011-5-30 15:50 发表


那就是把 xsd 先 map 成对象?
用户传上来的 xml 先变成对象
然后save to db ?

用xsd来match xml，把xml数据变object,然后存db.

kr2000

把需要的数据的columns跟xml的字段做一个mapping
parse成object
然后用这个mapping存数据库

说真的，我还想不到有神马其他的方法

[ 本帖最后由 kr2000 于 2011-5-30 15:56 编辑 ]

o2h2o

原帖由 乱码 于 2011-5-30 15:53 发表


用xsd来match xml，把xml数据变object,然后存db.

有啥 api 可以用 xsd 来 match xml 吗?
如果用户传一个 xml 用啥 api 来 match 是否 valid

bffbffbff

原帖由 典 于 2011-5-30 15:48 发表
Ignore me if I mis-understand you

What we did for xml to DB is: just pass the XML to a stored proc,
In the stored proc, merge xml-information to different tables.
We have hundreds of such procs to sa ...

我也觉得for log purpose， 整个存下来好， lz说的大概是你说的前一种情况，parse数据然后update到表里， 当然一开始xsd validate xml format。

o2h2o

原帖由 o2h2o 于 2011-5-30 15:59 发表

有啥 api 可以用 xsd 来 match xml 吗?
如果用户传一个 xml 用啥 api 来 match 是否 valid

找到了一个

http://support.microsoft.com/kb/318504

dalaohu

Too easy. When I get back home

bffbffbff

原帖由 o2h2o 于 2011-5-30 16:02 发表

找到了一个

http://support.microsoft.com/kb/318504

倒， 正要给你粘这个链接

乱码

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


等你等完全用熟xpath运用自如了你可能就愿意一切先放起来然后再处理了也说不定 ogay ？

haha, 喜欢你的小头像。

save raw data简单，以后query起来相对麻烦，但肯定可以克服，不行就用view先封装以下，其他人照样可以写东西。

最要命的是space，原来我接触的一个project，payment gateway给xml的response，我们把它原封不动save下来。

结果这个table每个月成2G的速率增长，我离开的时候已经占到DB总空间的40%.当然因为transaction多，才直接导致这个结果。

这部分是整个系统的core part,当大家意识到的时候，it's too late, refector工作量巨大，几乎不太可能。

我当时不是这个系统的designer,只是take over，但如果我来design的话，也可能偷懒会走这条路。

o2h2o

原帖由 乱码 于 2011-5-30 16:03 发表


haha, 喜欢你的小头像。

save raw data简单，以后query起来相对麻烦，但肯定可以克服，不行就用view先封装以下，其他人照样可以写东西。

最要命的是space，原来我接触的一个project，payment gateway给xml的response，我们把它 ...

是的 有相似经历
后来查起来太慢太痛苦

o2h2o

原帖由 dalaohu 于 2011-5-30 16:03 发表
Too easy. When I get back home

你的 头像真是大老虎了

bffbffbff

原帖由 乱码 于 2011-5-30 16:03 发表


haha, 喜欢你的小头像。

save raw data简单，以后query起来相对麻烦，但肯定可以克服，不行就用view先封装以下，其他人照样可以写东西。

最要命的是space，原来我接触的一个project，payment gateway给xml的response，我们把它 ...

恩，白条，确实惨痛的教训。
交易数量大的信息是够呛，我以前公司做的时候是把response内容关键信息解析更新数据库后再把xml response存到log文件夹里

linkspeed

XSD -> 转成 object
object -> plain object Entity framework -> db

我没试过，上个礼拜刚刚想到这种办法。
也许可以这样最大量的自动化生成代码。

这个前提是你的db talbe可以和object对应起来。
如果对应不起来，只好手工干涉了。

典

Parse in .Net as object and save to DB is OK, -- If you only have a few "lines "of data in a XML file

Parse in Stored Proc is supper fast if you have a lots of records in the XML file [PLUS] need to apply JOINs before insert --This is our scenario.

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

典

原帖由 乱码 于 2011-5-30 16:03 发表


haha, 喜欢你的小头像。

save raw data简单，以后query起来相对麻烦，但肯定可以克服，不行就用view先封装以下，其他人照样可以写东西。

最要命的是space，原来我接触的一个project，payment gateway给xml的response，我们把它 ...

Agreed
If the data will be used in query, absolutely shouldn't be in XML format

bffbffbff

说到这个ls几位老大都在，各位对xslt的感觉如何？ 小弟最近工作关系用了些xslt感觉很不错啊

乱码

原帖由 典 于 2011-5-30 16:15 发表
Parse in .Net as object and save to DB is OK, -- If you only have a few "lines "of data in a XML file

Parse in Stored Proc is supper fast if you have a lots of records in the XML file [PLUS] need to  ...

在DB那边作validation也好，可能需要些xpath的skill来存数据.

read的时候就正常操作了。

dalaohu

fistly, using visual studio to generates the strongly typed objects for all your .xsd. (there are some 3rd party tools too, but optional)

1. taking the incoming xml from you webservice and validates it against the .xsd
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 xml schema can be very different from db destination schemas, so it's good to have your xsd objects severed as a buffer layer.

3. and then depends on what Data layer you using, if ORM, then map the objects to POCO (there are 3rd tools for that) and hand over to data context for commit. if ADO, then doing the db commit manually.

bffbffbff

原帖由 乱码 于 2011-5-30 16:36 发表


在DB那边作validation也好，可能需要些xpath的skill来存数据.

read的时候就正常操作了。

proc 里解析确实很快，一般文件不大的xml需要的xpath的skill不需要说复杂，比较容易上手。

乱码

原帖由 bffbffbff 于 2011-5-30 16:33 发表
说到这个ls几位老大都在，各位对xslt的感觉如何？ 小弟最近工作关系用了些xslt感觉很不错啊

你喜欢这个？不错，它是当下很多人鼓吹的functional language，可能会有前景吧.

不过从syntax角度来看，它越来越被developer抛弃，ms从2006年决定用linq时，就把xslt depriciate了，所以它server那边的engine version一直是1.0,而不是像几个3rd party那样update到2.0.

有趣的是，vs2010竟然有个new feature是xslt debugger，只对xml file是local的才行，其他的datasource都不行。 当年刚出来的时候很不明白ms在搞什么，现在也不是很懂他们这样做的目的。

从自身发展角度来看，当下project极少用xslt，用这个的基本上都是老系统，但它不是很难，就看你喜欢不喜欢了，有的人很喜欢，不过这的确是少数。

将来的方向，ms这边有F#作functional language，xslt肯定从它这边没什么太大的出头之日了，也许会从其他open source领域冒头。

note: 好像典那边有些project还在一直用xslt，他应该更有发言权。

[ 本帖最后由 乱码 于 2011-5-30 16:58 编辑 ]

bffbffbff

原帖由 乱码 于 2011-5-30 16:49 发表


你喜欢这个？不错，它是当下很多人鼓吹的functional language，可能会有前景吧.

不过从syntax角度来看，它越来越被developer抛弃，ms从2006年决定用linq时，就把xslt depriciate了，所以它server那边的engine version一直是1.0, ...

白条2！ 老大就是牛

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

linkspeed

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 xml schema can be very different from db destination schemas, so it's good to have your xsd objects severed as a buffer layer.

business和data domain
不一样的话，他不是又要手工做一个转换？
我觉得他有几百个xsd，最好是弄成一样的，弄个大而全的。
中间要转换就麻烦透了。

linkspeed

xslt巨慢。。