关于.net下的Data Access技术

cdfei

这个完全是你们的个人选择了，我是觉得没有必要，我参与的项目都是结合使用。
我看见过有人这样做，我就在想，如果他们的项目要移植到ACCESS或者存储过程差别很大的其他数据库，他们就完蛋了。。。。

原帖由 乱码 于 2010-6-3 16:23 发表


我们公司都用sp，这是coding standard，如果一部分c#,一部分用sp，维护起来就更加麻烦。

至于找某个column/table name,除了通过sp的naming convention来找，也建议你看看下面的文章

http://blog.sqlauthor ...

dalaohu

原帖由 乱码 于 2010-6-3 16:23 发表

http://blog.sqlauthor ...

a 3 wrote this lol

just kidding

乱码

原帖由 cdfei 于 2010-6-3 16:29 发表
这个完全是你们的个人选择了，我是觉得没有必要，我参与的项目都是结合使用。
我看见过有人这样做，我就在想，如果他们的项目要移植到ACCESS或者存储过程差别很大的其他数据库，他们就完蛋了。。。。

good point!

的确，db平台移植，sp是很让人头疼，如果用ef,可以指定一下新的source就可以，不过成熟产品的移植的可能性有多大？

我做过一次，从sql server 2000到oracle，狠painful,不过也是我做过几十个project仅有的一个.

当时有些ormaping tool，但我们还没开始用，也不是每个ormaping可以完全屏蔽db的，linq to sql作移植也完蛋。如果不幸原来选中它，工作量只能更大。

很成熟的产品，db的移植可能性应该是更小了。

乱码

原帖由 dalaohu 于 2010-6-3 16:45 发表

a 3 wrote this lol

just kidding

he's one of sql server mvp i don't like somehow.

there's something valuable in his blog but much more misleading rubbish in there 2.

interestingly, he's blog always stay on top of google result set, he must be very good at seo stuff

[ 本帖最后由 乱码 于 2010-6-3 17:43 编辑 ]

典

我们这里有个SENIOR .NET Developer用 ASP.NET + Linq2SQL 做了个小项目，
总体上满意，代码写得很好，系统结构也很清晰。
但是Performance很差，在数据库用Profiler 来Monitor, 晕倒，也可能是哪里没弄好？

写代码的Productivity对我们来说毫无意义，一个项目只有40%左右的时间是写代码，然后写代码里大约20%是跟数据库有关的，Productivity提高几倍都没有意义。 Performance更重要。

flyspirit

还第一次听到有人说productivity没有意义的，不知道是你的想法还是你老板的想法。productivity不光是指写代码，还包括维护，调试，更改的productivity。

一味追求performance也没有意义，满足需求就行了。写汇编的人也可以说用高级语言写的代码大大影响性能，难道大家回到机器编码时代？

也不是说ORM适合所有情况，但很多solution中可以使用，而且慢慢成为需要掌握的技术之一了。

dotnet

I prefer stored procedure based O/R mapper than table based O/R mapper.
the input parameters -> request message, the output parameters -> response message

10xFaster

上次在参加microsoft的产品宣传会还见到过scott gutherie, 在seattle...

10xFaster

他很懂技术，在microsoft高层中有如此"still gets his hands dirty" 的真不多！！！

dalaohu

原帖由 乱码 于 2010-6-3 17:41 发表
he's one of sql server mvp i don't like somehow.
there's something valuable in his blog but much more misleading rubbish in there 2.
interestingly, he's blog always stay on top of google res ...

不是我种族歧视，阿三们真的是略等民族， 当然巴基斯坦就不提了。
刚出道时的小公司，小项目跟他们都打过交道。真的不提了。有个巴基斯坦的还在办公室里佩刀，搞恐怖行为。
有幸的是现在的大项目里这些人基本绝迹了，偶有个印度的tester，还是皮肤比较白的那种，算是高尚的那种。接触久了，那种骨子里的劣根性你就看出来了 - 懒惰，狭窄，底子，技术差，好色，贪杯，爱小便宜。

乱码

原帖由 10xFaster 于 2010-6-3 22:03 发表
他很懂技术，在microsoft高层中有如此"still gets his hands dirty" 的真不多！！！

从bill gates开始，ms高层的style就是懂技术又要懂business.

scott gu是技术方面的高层，写些技术方面的article不费吹灰之力，更何况是high level的developer如何用，而不是很low level的如何实现。

而且scott在.net community的影响力很大，利用他的影响力来对某些new product/new features通过blog/巡讲作宣传，是ms marketing策略之一，同ms弄这么多在活跃在community的mvp是一个意思。

典

原帖由 dalaohu 于 2010-6-3 22:45 发表


不是我种族歧视，阿三们真的是略等民族， 当然巴基斯坦就不提了。
刚出道时的小公司，小项目跟他们都打过交道。真的不提了。有个巴基斯坦的还在办公室里佩刀，搞恐怖行为。
有幸的是现在的大项目里这些人基本 ...

这么恐怖？

乱码

原帖由 dalaohu 于 2010-6-3 22:45 发表


不是我种族歧视，阿三们真的是略等民族， 当然巴基斯坦就不提了。
刚出道时的小公司，小项目跟他们都打过交道。真的不提了。有个巴基斯坦的还在办公室里佩刀，搞恐怖行为。
有幸的是现在的大项目里这些人基本 ...

我跟阿三兄弟姐妹还算是和谐，听说他们那边等级很分明，可能我接触的人大多是社会阶层相对比较高，相对家庭教育比较好的人。

不过也有很烂的人，可能都是孟买胡同出来的，这种人的素质连他们同胞都很不耻，更何况我们了。

dalaohu

Basically their skin color determined social status.

Maybe light skin ones won't expose as easier as darker ones.

In programming word. They implement different interface but inherit from the same base class.

See I just gave another easy to understand coding lesson here

cdfei

哦，区别只是factory不一样哇

原帖由 dalaohu 于 2010-6-4 10:18 发表
Basically their skin color determined social status.

Maybe light skin ones won't expose as easier as darker ones.

In programming word. They implement different interface but inherit from the s ...

cdfei

不会的，你自己可以做做测试，但不要用orm就啥都orm，一些复杂的应用，对数据多表的复杂访问，你必须自己directly against data source，这个在EF4中也有提供。

原帖由 典 于 2010-6-3 18:25 发表
我们这里有个SENIOR .NET Developer用 ASP.NET + Linq2SQL 做了个小项目，
总体上满意，代码写得很好，系统结构也很清晰。
但是Performance很差，在数据库用Profiler 来Monitor, 晕倒，也可能是哪里没弄好？

写 ...

cdfei

还有一个考虑就是，增加一台应用服务器是比较容易的，但增加一个数据库服务就很难了，程序也要改，所以你如果将业务逻辑SP封装在数据库中，增加了数据服务器的负荷，以后的硬件扩展就是个问题

原帖由 乱码 于 2010-6-3 17:35 发表


good point!

的确，db平台移植，sp是很让人头疼，如果用ef,可以指定一下新的source就可以，不过成熟产品的移植的可能性有多大？

我做过一次，从sql server 2000到oracle，狠painful,不过也是我做过几十个p ...

flyspirit

原帖由 cdfei 于 2010-6-4 10:40 发表
还有一个考虑就是，增加一台应用服务器是比较容易的，但增加一个数据库服务就很难了，程序也要改，所以你如果将业务逻辑SP封装在数据库中，增加了数据服务器的负荷，以后的硬件扩展就是个问题

Can't agree more

乱码

原帖由 cdfei 于 2010-6-4 10:40 发表
还有一个考虑就是，增加一台应用服务器是比较容易的，但增加一个数据库服务就很难了，程序也要改，所以你如果将业务逻辑SP封装在数据库中，增加了数据服务器的负荷，以后的硬件扩展就是个问题

根据我以往几十个project的经验（since i was junior)，

1。一般的应用都是app/web server忙死， database server闲死，database做得最多的就是crud，这对动辄上20k的db server来说是一种绝对的资源浪费，所以我们用sp，让database"活"起来, 用javescript/jquery让client的brower活起来，从而减轻web/app server的负担。sp如果被认为data的api应该更为合理。

2。.net developer除了.net skills，还要在sql & javascript上加强，这也是为什么.net developer喜欢把logic 用c#来实现。

3。如果logic都在app/web server side实现，database就会成为单纯的data store,这在日新月异的。net领域可能没有什么问题，但在更有历史的database领域，会被认为是丝毫不可以接受的design。

3。data has much longer life than app/web，这不是我说的，这是业界公认的，data会永存(可能有50-100年，比如金融数据），相应的数据库迁移可能性也非常小，db2/informatics/oracle即使10年不做更新，照样还有很多公司在用。但app platform会迁移，想想现在谁还在用classic asp?（虽然有些，classic asp技术在1997年还没有几个人懂得,但2008年几乎没有人在用它开发新产品了）.net可能会存在10-20年，但20年之后呢？谁敢说自己的平台20年后会run在ms的平台上？

基本上每个team都会用自己认为最合适的practice，这可以理解，但要倾听一下其他领域的人如何来review,我刚好在.net&database都有几年的经验，我说的代表相当一部分community的观点,可能对他们的design有点价值，我想。

[ 本帖最后由 乱码 于 2010-6-4 12:04 编辑 ]

cdfei

谢谢你的经验分享。
我们的经验不一样，我在国内创建参与的项目中，特别是银行，数据库负荷过重，导致应用层的数据联接超时经常发生，因为客户的数据库服务器往往支持不只一个应用，所以我们经常的优化就是减轻数据库的负担。
在澳洲还真没有参加过大项目。

flyspirit

你狡猾的把概念偷换了，data不变不代表处理data的logic不变。实际上logic经常可能要改动以满足新的业务需求。在ORM改动的要比在SP层面容易得多。这是ORM越来越受欢迎的原因之一。

你提出的classic ASP, .NET会消亡没有错，但搞错比较对象了。这里比较的是3层架构和以前的两层结构设计的差别。3曾结构倡导的是展示层-逻辑层-数据层的分离。这个理念和具体开发工具是.net, java, php, python没有关系。

北风

对数据进行处理，当然是数据库的责任之一。不过这种处理应该限于一般性的处理，更多的逻辑方面的处理应该让app去完成
也可以这么说，大多数情况下一个数据库的sp不是为了一个app特别服务的。它应该具有一定的一般性。

其实performance的问题在app和database两边都会存在
而datbase的performance问题往往是在长久使用之后才会出现的，所以看他清闲很可能是暂时性的

原帖由 乱码 于 4/6/2010 11:21 发表


根据我以往几十个project的经验（since i was junior)，

1。一般的应用都是app/web server忙死， database server闲死，database做得最多的就是crud，这对动辄上20k的db server来说是一种绝对的资源浪费，所以我们用sp，让database"活"起来, 用javescript/jquery让client的brower活起来，从而减轻web/app server的负担。sp如果被认为data的api应该更为合理。

2。.net developer除了.net skills，还要在sql & javascript上加强，这也是为什么.net developer喜欢把logic 用c#来实现。

3。如果logic都在app/web server side实现，database就会成为单纯的data store,这在日新月异的。net领域可能没有什么问题，但在更有历史的database领域，会被认为是丝毫不可以接受的design。

3。data has much longer life than app/web，这不是我说的，这是业界公认的，data会永存(可能有50-100年，比如金融数据），相应的数据库迁移可能性也非常小，db2 /informatics/oracle即使10年不做更新，照样还有很多公司在用。但app platform会迁移，想想现在谁还在用classic asp?（虽然有些，classic asp技术在1997年还没有几个人懂得,但2008年几乎没有人在用它开发新产品了）.net可能会存在10-20年，但20年之后呢？谁敢说自己的平台20年后会run在ms的平台上？

基本上每个team都会用自己认为最合适的practice，这可以理解，但要倾听一下其他领域的人如何来review,我刚好在.net&database都有几年的经验，我说的代表相当一部分community的观点,可能对他们的design有点价值，我想。

乱码

database logic随时可以变，如果database比前端平台生命周期长很多，business logic都是在前端实现的，一旦前端的平台变了，是不是要重新写business logic? 如果把sp认为是data的api, 无论前端如何变，就只是consume sp (data的api)就好，从这个意义上来说，是在节省成本，而且有利于维护（想象一下十年后把今天写的logic用其他语言replicate是何等painful)。

我们也是3 tier,不过把business logic layer 放在database里面。 严格的说用上ormaping tool，有的app就变成两层了，data access消失了。

乱码

原帖由 北风 于 2010-6-4 14:46 发表
大多数情况下一个数据库的sp不是为了一个app特别服务的。它应该具有一定的一般性

请解释一下这句话，谢谢！！

乱码

原帖由 cdfei 于 2010-6-4 13:39 发表
谢谢你的经验分享。
我们的经验不一样，我在国内创建参与的项目中，特别是银行，数据库负荷过重，导致应用层的数据联接超时经常发生，因为客户的数据库服务器往往支持不只一个应用，所以我们经常的优化就是减轻数据 ...

我们的database server在hosting company那边是dedicated box，只有一个application在上面跑，所以不存在其他app data影响的问题。

我们也有连接超时的情况发生，不过都是data modeling阶段出的design flaw, 现阶段基本上改不了，只好从input parameter上限制，so bad...

我猜你的问题可以把不同的data为不同的app放在不同的box里面,用distributed database model解决数据交换问题，这样可能可以有效的缓解负担过重的问题，但要注意大数据量引起的traffic，

我不了解情况，瞎猜得。

[ 本帖最后由 乱码 于 2010-6-4 16:34 编辑 ]

flyspirit

你对3 tier的理解不对啊。3 tier中的每个tier之间是物理独立的，可以单独部署并扩展。你的SP和数据库服务器是不能分开的，怎么会是3 tier?

乱码

原帖由 flyspirit 于 2010-6-4 16:38 发表
你对3 tier的理解不对啊。3 tier中的每个tier之间是物理独立的，可以单独部署并扩展。你的SP和数据库服务器是不能分开的，怎么会是3 tier?

传统意义上的3 tier理论上可以bl和da物理上分离，分别部署，但真正这么做的有几个？有了ormapping,这么做更加是不可能。甚至把presentation和bl分开的都不多。

flyspirit

不少的，SOA架构下的大多都会这么做。Java World也有很多。那些Applications Server是什么？不会是数据库吧。

北风

举个例子，有个database有2个app都要对它里面的一个table做相似的update，当然这2个app的update有不同的条件
我们需要1个sp，在app里面处理条件呢？还是2个sp，然后在sp里面分别处理条件呢？

这样说可能清楚一点，这其实就是两层合并成一层，看似简单了其实：
本来一件事情需要分两步做，但是如果一定要合成一步做，就会把一件事情分成了两件事情（如果有n个条件，就是n件事情）

原帖由 乱码 于 4/6/2010 16:11 发表


请解释一下这句话，谢谢！！

乱码

原帖由 flyspirit 于 2010-6-4 16:57 发表
不少的，SOA架构下的大多都会这么做。Java World也有很多。那些Applications Server是什么？不会是数据库吧。

动不动就用soa其实是个误区，大系统用soa的确可以增加它的scalibility，但诚实的说这种project少之又少，5%都不到。

app server跟你说的web server是一个概念，app 在那个server上跑。