前者数据传输一律封装为DataSet，后者却是自定义类和IList接口组合。
封装为DataSet的好处是：编码简单，界面显示支持完善，离线处理功能强大，数据库支持好；缺点：封装后数据量庞大，性能依赖微软，增加网络传输量；
自定义类好处是：数据量小，结构精巧，可以自定义，完全面向对象；缺点：数据库支持差，界面显示可能需要编码。
大家认为那种标准更好?欢迎讨论。
18 个解决方案
#1
全被你說了﹐還有說的嗎﹖
#2
不同的情况采用不同的方式咯，呵呵。
#3
请问Duwamish怎么安装啊？
提示要先安装IIS，但是实际上已经装过了。
我的操作系统是Server 2003。
提示要先安装IIS，但是实际上已经装过了。
我的操作系统是Server 2003。
#4
安完VS.NET后到Duwamish所在目录找到安装程序，再运行才真安装。
我感觉后者应该是大中型系统的方法，前者是一般小型系统的方法。
我感觉后者应该是大中型系统的方法，前者是一般小型系统的方法。
#5
自定义类好！界面显示*度大啊！
#6
是找的这个安装程序，运行时出现的提示。
#7
恰恰相反，Duwamish才是真正适合大型系统的方法，而Petshop的实现适合中小型系统
#8
Duwamish采用DataSet传输封装数据，而微软.net中的DataSet和ado中的recordset存在本质的区别就是.Net中的Dataset是一种离线的数据集，也就是数据填充到Dataset中以后数据连接就被释放掉了，而数据连接对于大型系统来说是个十分重要的资源，它最终决定了系统并发支持的用户的数量。Duwamish一旦数据被读取，就释放连接资源，而下一次使用数据连接的时刻是客户端对于真个dataset编辑过后需要更新数据库的时候，这样每批数据只用连接两次数据库就可以了。对于每次读取数据量很大，我向通过数据的缓存应该能够缓解。
而petshop使用datareader和自定义的数据结构来储存数据，保证了网络上传输的数据量的最小值，也保证了它响应的快速。但是datareader是当访问数据时才向服务器所求数据的对象，数据在打开到被访问期间数据连接一直被占用，相对于Duwamish这点这方面明显不同，在大型应用大并发的情况下应该不太合适。
而petshop使用datareader和自定义的数据结构来储存数据，保证了网络上传输的数据量的最小值，也保证了它响应的快速。但是datareader是当访问数据时才向服务器所求数据的对象，数据在打开到被访问期间数据连接一直被占用，相对于Duwamish这点这方面明显不同，在大型应用大并发的情况下应该不太合适。
#9
同意楼上的。！
关键在你的站点定义的性能和数据量！
有关这方面的详细讨论在martin flower的《P of E A A》一书里有详细说明
关键在你的站点定义的性能和数据量！
有关这方面的详细讨论在martin flower的《P of E A A》一书里有详细说明
#10
gaisylly所说的主要是数据连接(connection)的问题。
仔细看看petshop，就会发现凡是使用Datareader的地方都用了using子句，而using子句的特点就是可以立刻释放资源。
而且子句内的内容只是把数据填充的自定义类中，没有别的目的，个人认为不会比填充dataset更慢。所以从这个角度二者没有区别。
仔细看看petshop，就会发现凡是使用Datareader的地方都用了using子句，而using子句的特点就是可以立刻释放资源。
而且子句内的内容只是把数据填充的自定义类中，没有别的目的，个人认为不会比填充dataset更慢。所以从这个角度二者没有区别。
#11
dataset的OO概念不强
自定义类的话实现or-map 性能肯定是会受到损失的
但相反我觉得企业级应用性能是靠硬件去提升的 所以可以允许一定的性能损失
个人推荐petshop的做法,Duwamish提供的一种比较典型的MS式的快速开发做法
但任何一种方法都应该使用后立即释放数据库连接
这和选用哪种数据传输方法无关
自定义类的话实现or-map 性能肯定是会受到损失的
但相反我觉得企业级应用性能是靠硬件去提升的 所以可以允许一定的性能损失
个人推荐petshop的做法,Duwamish提供的一种比较典型的MS式的快速开发做法
但任何一种方法都应该使用后立即释放数据库连接
这和选用哪种数据传输方法无关
#12
// 但相反我觉得企业级应用性能是靠硬件去提升的
能提升多少?
不敢苟同
能提升多少?
不敢苟同
#13
我也觉得DataSet好
因为:
数据操作,瓶颈几乎全在数据库.并且微软的DataAdapter+DataSet模型,能很大程度上减少无畏的数据库资源浪费.
网络传输方面,如果是在内部网络之间的传输,不太可能有速度问题.
而系统处理DataSet的速度也是很快的.并且,从用DataSet加载和填充数据非常方便,自定义类,要做到这些虽说也不难,但是我想很难做到像DataSet这么棒的模型吧,虽说速度方面针对具体逻辑写的类可能确实要快一点
因为:
数据操作,瓶颈几乎全在数据库.并且微软的DataAdapter+DataSet模型,能很大程度上减少无畏的数据库资源浪费.
网络传输方面,如果是在内部网络之间的传输,不太可能有速度问题.
而系统处理DataSet的速度也是很快的.并且,从用DataSet加载和填充数据非常方便,自定义类,要做到这些虽说也不难,但是我想很难做到像DataSet这么棒的模型吧,虽说速度方面针对具体逻辑写的类可能确实要快一点
#14
我觉得学习的时候应该用petshop的方法
#15
如果采用OO设计的话，应该采用自定义类 ＋ ORMapping来实现，这样可以使自己的业务实体和数据库结构分开，而且自定义类相比DataSet而言，更加轻量。
DataSet本身和数据库的相关性，一方面同样向上层暴露出了数据库的结构，第二方面，如果不采用strong typed DataSet的话，上层应用还需要用字段名来访问数据，不能实现类的.属性名操作。
DataSet本身和数据库的相关性，一方面同样向上层暴露出了数据库的结构，第二方面，如果不采用strong typed DataSet的话，上层应用还需要用字段名来访问数据，不能实现类的.属性名操作。
#16
这两程方式我在开发中都用过,要是系统可以自己设计数据传送,尽量不要用DataSet,它会把你的内存吃光!!!还会出现很多意想不到的错误.
#17
gz
#18
DataSet在Duwamish的使用确实让初学者感觉很舒服，而且有企业级模板做为后腰，因此大家都会偏向它。但是经过具体分析和实际运用，发现很多问题。
首先，Duwamish中的数据关系看似复杂，很多表格都是N对N的。但是往上层看看就会发现里面有一些破绽——很多数据项在上层都未使用。相应的在多层之间传递的DataSet通常只是一个二维的表，而对于父子关系，多对多关系一概不见。
其次，像上面的人兄说得，DataSet在企业级模板中的应用，就和OO差的八丈远了。因此也就只适合快速的、关系简单的应用了。
还有在实际使用的时候，DataSet的设计越来越依赖与数据库的设计，并考虑一些Web的现实结果，其它的什么都没有了。
不过我们应该在实际应用中根据具体情况将DataSet的设计和自定义的设计相结合，而不能拘泥于一种方式。
首先，Duwamish中的数据关系看似复杂，很多表格都是N对N的。但是往上层看看就会发现里面有一些破绽——很多数据项在上层都未使用。相应的在多层之间传递的DataSet通常只是一个二维的表，而对于父子关系，多对多关系一概不见。
其次，像上面的人兄说得，DataSet在企业级模板中的应用，就和OO差的八丈远了。因此也就只适合快速的、关系简单的应用了。
还有在实际使用的时候，DataSet的设计越来越依赖与数据库的设计，并考虑一些Web的现实结果，其它的什么都没有了。
不过我们应该在实际应用中根据具体情况将DataSet的设计和自定义的设计相结合，而不能拘泥于一种方式。
#1
全被你說了﹐還有說的嗎﹖
#2
不同的情况采用不同的方式咯，呵呵。
#3
请问Duwamish怎么安装啊？
提示要先安装IIS，但是实际上已经装过了。
我的操作系统是Server 2003。
提示要先安装IIS，但是实际上已经装过了。
我的操作系统是Server 2003。
#4
安完VS.NET后到Duwamish所在目录找到安装程序，再运行才真安装。
我感觉后者应该是大中型系统的方法，前者是一般小型系统的方法。
我感觉后者应该是大中型系统的方法，前者是一般小型系统的方法。
#5
自定义类好！界面显示*度大啊！
#6
是找的这个安装程序，运行时出现的提示。
#7
恰恰相反，Duwamish才是真正适合大型系统的方法，而Petshop的实现适合中小型系统
#8
Duwamish采用DataSet传输封装数据，而微软.net中的DataSet和ado中的recordset存在本质的区别就是.Net中的Dataset是一种离线的数据集，也就是数据填充到Dataset中以后数据连接就被释放掉了，而数据连接对于大型系统来说是个十分重要的资源，它最终决定了系统并发支持的用户的数量。Duwamish一旦数据被读取，就释放连接资源，而下一次使用数据连接的时刻是客户端对于真个dataset编辑过后需要更新数据库的时候，这样每批数据只用连接两次数据库就可以了。对于每次读取数据量很大，我向通过数据的缓存应该能够缓解。
而petshop使用datareader和自定义的数据结构来储存数据，保证了网络上传输的数据量的最小值，也保证了它响应的快速。但是datareader是当访问数据时才向服务器所求数据的对象，数据在打开到被访问期间数据连接一直被占用，相对于Duwamish这点这方面明显不同，在大型应用大并发的情况下应该不太合适。
而petshop使用datareader和自定义的数据结构来储存数据，保证了网络上传输的数据量的最小值，也保证了它响应的快速。但是datareader是当访问数据时才向服务器所求数据的对象，数据在打开到被访问期间数据连接一直被占用，相对于Duwamish这点这方面明显不同，在大型应用大并发的情况下应该不太合适。
#9
同意楼上的。！
关键在你的站点定义的性能和数据量！
有关这方面的详细讨论在martin flower的《P of E A A》一书里有详细说明
关键在你的站点定义的性能和数据量！
有关这方面的详细讨论在martin flower的《P of E A A》一书里有详细说明
#10
gaisylly所说的主要是数据连接(connection)的问题。
仔细看看petshop，就会发现凡是使用Datareader的地方都用了using子句，而using子句的特点就是可以立刻释放资源。
而且子句内的内容只是把数据填充的自定义类中，没有别的目的，个人认为不会比填充dataset更慢。所以从这个角度二者没有区别。
仔细看看petshop，就会发现凡是使用Datareader的地方都用了using子句，而using子句的特点就是可以立刻释放资源。
而且子句内的内容只是把数据填充的自定义类中，没有别的目的，个人认为不会比填充dataset更慢。所以从这个角度二者没有区别。
#11
dataset的OO概念不强
自定义类的话实现or-map 性能肯定是会受到损失的
但相反我觉得企业级应用性能是靠硬件去提升的 所以可以允许一定的性能损失
个人推荐petshop的做法,Duwamish提供的一种比较典型的MS式的快速开发做法
但任何一种方法都应该使用后立即释放数据库连接
这和选用哪种数据传输方法无关
自定义类的话实现or-map 性能肯定是会受到损失的
但相反我觉得企业级应用性能是靠硬件去提升的 所以可以允许一定的性能损失
个人推荐petshop的做法,Duwamish提供的一种比较典型的MS式的快速开发做法
但任何一种方法都应该使用后立即释放数据库连接
这和选用哪种数据传输方法无关
#12
// 但相反我觉得企业级应用性能是靠硬件去提升的
能提升多少?
不敢苟同
能提升多少?
不敢苟同
#13
我也觉得DataSet好
因为:
数据操作,瓶颈几乎全在数据库.并且微软的DataAdapter+DataSet模型,能很大程度上减少无畏的数据库资源浪费.
网络传输方面,如果是在内部网络之间的传输,不太可能有速度问题.
而系统处理DataSet的速度也是很快的.并且,从用DataSet加载和填充数据非常方便,自定义类,要做到这些虽说也不难,但是我想很难做到像DataSet这么棒的模型吧,虽说速度方面针对具体逻辑写的类可能确实要快一点
因为:
数据操作,瓶颈几乎全在数据库.并且微软的DataAdapter+DataSet模型,能很大程度上减少无畏的数据库资源浪费.
网络传输方面,如果是在内部网络之间的传输,不太可能有速度问题.
而系统处理DataSet的速度也是很快的.并且,从用DataSet加载和填充数据非常方便,自定义类,要做到这些虽说也不难,但是我想很难做到像DataSet这么棒的模型吧,虽说速度方面针对具体逻辑写的类可能确实要快一点
#14
我觉得学习的时候应该用petshop的方法
#15
如果采用OO设计的话，应该采用自定义类 ＋ ORMapping来实现，这样可以使自己的业务实体和数据库结构分开，而且自定义类相比DataSet而言，更加轻量。
DataSet本身和数据库的相关性，一方面同样向上层暴露出了数据库的结构，第二方面，如果不采用strong typed DataSet的话，上层应用还需要用字段名来访问数据，不能实现类的.属性名操作。
DataSet本身和数据库的相关性，一方面同样向上层暴露出了数据库的结构，第二方面，如果不采用strong typed DataSet的话，上层应用还需要用字段名来访问数据，不能实现类的.属性名操作。
#16
这两程方式我在开发中都用过,要是系统可以自己设计数据传送,尽量不要用DataSet,它会把你的内存吃光!!!还会出现很多意想不到的错误.
#17
gz
#18
DataSet在Duwamish的使用确实让初学者感觉很舒服，而且有企业级模板做为后腰，因此大家都会偏向它。但是经过具体分析和实际运用，发现很多问题。
首先，Duwamish中的数据关系看似复杂，很多表格都是N对N的。但是往上层看看就会发现里面有一些破绽——很多数据项在上层都未使用。相应的在多层之间传递的DataSet通常只是一个二维的表，而对于父子关系，多对多关系一概不见。
其次，像上面的人兄说得，DataSet在企业级模板中的应用，就和OO差的八丈远了。因此也就只适合快速的、关系简单的应用了。
还有在实际使用的时候，DataSet的设计越来越依赖与数据库的设计，并考虑一些Web的现实结果，其它的什么都没有了。
不过我们应该在实际应用中根据具体情况将DataSet的设计和自定义的设计相结合，而不能拘泥于一种方式。
首先，Duwamish中的数据关系看似复杂，很多表格都是N对N的。但是往上层看看就会发现里面有一些破绽——很多数据项在上层都未使用。相应的在多层之间传递的DataSet通常只是一个二维的表，而对于父子关系，多对多关系一概不见。
其次，像上面的人兄说得，DataSet在企业级模板中的应用，就和OO差的八丈远了。因此也就只适合快速的、关系简单的应用了。
还有在实际使用的时候，DataSet的设计越来越依赖与数据库的设计，并考虑一些Web的现实结果，其它的什么都没有了。
不过我们应该在实际应用中根据具体情况将DataSet的设计和自定义的设计相结合，而不能拘泥于一种方式。