讨论do.net下如何很好的实现MVC模式的开发(200分)

讨论do.net下的数据访问层实现方法
讨论do.net下的业务层实现方法 等

我们用强类型数据集，也试用过NHiberate和iBatisNet，现在在准备做自己的ORM []

强类型数据集是否没有像NHiberate下的Value Object,业务对象要全部手工实现，而且在表现层也不太方便进行数据邦定特别是GUI方式
NHiberate如果表结构栏位很多，而且时只需要读取部分时，这样会不会影响性能，还望高手指点！谢谢！

采用强类型数据集和hibernate的强类型对象，都有如下的缺陷：
{
缺点
•
可能需要太多的类。如果选择了使用强类型的 DTO，则可能必须为每个远程方法创建一个（如果考虑返回值，则为两个）DTO。即使在粗粒度接口中，这也可能导致大量的类。编写如此数量的类的代码并管理这些类会是很困难的。使用自动代码生成可以在一定程度上缓解此问题。

•
增加计算量。如果将服务器上的一种数据格式转换为可以跨网络传输的字节流，并在客户端应用程序内转换回对象格式，可以带来相当大的开销。通常，需要将来自多个源的数据聚合到服务器上的单个 DTO 中。要提高通过网络进行远程调用的效率，必须在任一端执行其他计算，才能聚合和串行化信息。

•
增加编码工作量。可以用一行代码完成将参数传递到方法的操作。使用 DTO 要求实例化新对象，并为每个参数调用 setters 和 getters。编写此代码可能是很乏味的。

}
上述是MSDN上摘录的。
我的想法是，构建一个通用的持久层，实现非类型化数据集的数据增、删、改、查，可极大提高开发效率，并且可以和数据绑定控件契合使用，这种架构也能符合实际开发项目中需求经常变动大的状况，至少不必重新翻查大堆的代码（即使使用工具也是费心费力的）。
本人已在Delphi上实现过一个通用持久层引擎，正计划在ADO.NET+C#上也如法炮制一个，也想听听大家的意见。

强类型数据集的优缺点可参考‘ADO.NET Core Reference’中第九章相关论述。
对于表现层，采用数据集（不管是强类型还是非类型化），可以不费力的和数据感知控件进行绑定，以减少表现层的代码量；
如果表现层是不需要做数据绑定的，那推荐使用强类型数据集，而hibernate模式在此情景中也就有了存在的价值。

Dot Net还是do.net ?