*** 高分请教几个关于.Net在WinForm下的三层的问题 ***
请高手注意，我的问题的前提是WinForm   +   三层，而且我的目标系统是大型
应用系统（如ERP）

1、三层结构中在不同层是传递DataSet（强类型）好，还是传递实体类好？
如果是传递DataSet，感觉UI层的DataBinding比较好作点，但整体结构不够
清晰，从三层的理论来作，对UI层和逻辑层还是过多的牵涉了数据的操作。
如果是传递实体类，整体结构很清晰，但感觉编码量大（大型系统要作N多的
实体类），而且UI层DataBinding不很方便

2、数据层如何作持久连接或者连接池？看了几个三层的系统都是数据层每次
接受到逻辑层的调用都开一个连接，用完再关的，这样对响应要求很高的系
统，效率上肯定会慢。

请高手回答我的问题，我刚学.Net三天（五一期间学的），请高手讲清楚点。
分不够可以再加

------解决方案--------------------
1、三层结构中在不同层是传递DataSet（强类型）好，还是传递实体类好？
===================================================================
个人比较习惯实体类，估计是接触过的项目还太小

2、数据层如何作持久连接或者连接池？看了几个三层的系统都是数据层每次
接受到逻辑层的调用都开一个连接，用完再关的，这样对响应要求很高的系
统，效率上肯定会慢
===================================================================
关了连接，只是归还到连接池，并不是真的关了
还有，效率和程序的可维护性，有时候可能不得不做某种平衡...否则根本不分层显然是最快的
------解决方案--------------------
1.没有哪个较好，你习惯了就好。我觉得没有一个固定的说法。
2.我习惯了用完了就关，或者使用Using语句，可能有更好的做法，但习惯了，懒得改。
------解决方案--------------------
企业应用（ERP即是企业应用）软件，尤其是大型企业应用软件，分几层，如何划分系统结构，是系统架构师的事情，所以肯定不能笼统地认为它是三层或是多少层的结构，软件结构的划分与企业的结构有关系。

所以：

1、采用实体类或是DataSet/DataTable都是可以的，取决于系统的复杂度和逻辑的复杂度以及数据的复杂度。

2、连接字符串中可以直接指定启用连接池，SQL Server默认也启用了连接池，当然，作为WinForm项目，自己管理维护一个连接池也是可以的。
------解决方案--------------------
那就实体的，REF
------解决方案--------------------
2、数据层如何作持久连接或者连接池？看了几个三层的系统都是数据层每次
接受到逻辑层的调用都开一个连接，用完再关的，这样对响应要求很高的系
统，效率上肯定会慢。

效率你是可以放心的，MVC 就是为了，提高效率的， 不然还要分层干什么，

但感觉编码量大 ???????????
我不认为这样的， 那有？ M做好了就直接用， C层就直接调用，很多代码都剩了，不用重复的敲，M层是通用的
------解决方案--------------------
我学这个MVC就学了 好多天， 兄弟这个要慢慢的理解， 时间长了你会知道的
------解决方案--------------------
1、三层结构中在不同层是传递DataSet（强类型）好，还是传递实体类好？
如果是传递DataSet，感觉UI层的DataBinding比较好作点，但整体结构不够
清晰，从三层的理论来作，对UI层和逻辑层还是过多的牵涉了数据的操作。
如果是传递实体类，整体结构很清晰，但感觉编码量大（大型系统要作N多的
实体类），而且UI层DataBinding不很方便

===
我是传实体，如果是物理3层，则可能用到remoting，但性能不太好


2、数据层如何作持久连接或者连接池？看了几个三层的系统都是数据层每次
接受到逻辑层的调用都开一个连接，用完再关的，这样对响应要求很高的系
统，效率上肯定会慢。

=====

.net平台会管理好连接池的，不用自己去关闭。

------解决方案--------------------
实体层优点:
(1)代码可维护性强,比如说可以直接在代码上加注释,并且智能提示会在以后表现层应用中发挥做用.
(2)编程比较灵活,不会受到强类型数据集的一些限制.
(3)可以方便应用一些设计模式解决特殊问题,比如说异种数据库应用.
缺点是代码量大,但这个可以通过应用代码生成器来解决.实际上vs.net2007beta1版本中,已经能生成model代码,其他的没有深入研究,希望正式版出来以后,可以看到更多的代码生成.

------解决方案--------------------
实体层优点:
(1)代码可维护性强,比如说可以直接在代码上加注释,并且智能提示会在以后表现层应用中发挥做用.
(2)编程比较灵活,不会受到强类型数据集的一些限制.
(3)可以方便应用一些设计模式解决特殊问题,比如说异种数据库应用.
缺点是代码量大,但这个可以通过应用代码生成器来解决.实际上vs.net2007beta1版本中,已经能生成model代码,其他的没有深入研究,希望正式版出来以后,可以看到更多的代码生成.


事实上代码的可维护性取决于两点，一是代码的质量，而是代码的数量，质量低而数量高的代码难以维护而质量高数量低的代码易于维护。

为什么C#和Java会风靡一时？究其底还是同样的功能代码量比C++要少很多，代码量少就意味着可维护性高。

程序出问题的概率等于代码数量/代码质量，这个应该很容易理解吧。

一个毫无意义实体类除了增加你的代码量没有任何好处，这是实体类的硬伤之一。

1、所以所谓的实体类维护方便是毫无根据的，文档齐备、数据库访问层设计合理的架构，是更易于维护的。

DataSet/DataTable/DataView设计伊始就将数据绑定考虑了进去，并且在这中间，所有的接口都是开放性的，如ITypedList、ITypeDescriptor，这些接口，均是public的，在DataTable/DataView上做二次开发并不是件难事，况且数据集是一个广义的概念，一种手法而已。

2、所谓的数据集有什么限制，我从未遇到过。
3、什么乱七八糟的……不知所云……DataSet和DataTable从未与某种单一的数据库扯上关系。至于设计模式，总是用来衬托自己的学问高深，掩饰这种不知所云的言论。

VS2007增加的内容可以说多多少少都与数据访问有关系，如lambda表达式、LINQ语法、匿名类型和各种构造器等。但无论什么时候，抽象，和在语法层面解决问题，始终是首选，C#的风格就是尽可能的节省代码，所谓的代码生成器，在项目开发中，应该始终是无法成为主流的。代码解析器（CodeParser）则可能有更大的发展空间，如WPF、ASP.NET等，代码解析器将成为脚本与高级强类型程序设计语言之间的桥梁发挥越来越大的作用。