ASP.NET做三层（或者多层）的架构讨论
我以前使用Delphi的，现在才进入.NET开发环境。现在因为要做一个B/S系统，正在想架构问题，希望有人能够给我一些指导。
在.NET中很重要的一个组件就是DataSet，这个是学Delphi的Midas技术，对这点我非常熟悉，毕竟使用Delphi已经好几年了。
DataSet的可以让数据更新一个整体的概念进行数据的存储工作，如订单的明细表的修改、添加或者删除，可以一股脑提交给服务端集中处理。这样对我的体验是：干净。.NET使用DataSet是一个很大的特色。
但是我在ASP.NET的介绍中并没有看到DataSet的优点。在ASP.NET中，数据的存储使用SQLDataSource、ObjectDataSource，这些DataSource实际使用SQL语句或者TableAdapter捆绑的SQL语句进行数据的访问和更新，并没有打包的概念。是不是我了解的太少了？
看了WebCast只是说ASP.NET开发数据库应用很方便。是的，的确很方便，但这些是属于轻量级的。ObjectDataSource可以使用自定义的业务对象，但是这些业务对象的接受只能是一些基本参数，不能包含Master/Detail数据，这样如果要保存一个订单，只能先保存主信息，再让用户点击页面按钮保存明细信息－－这是不能忍受的。我举的这个例子比较简单，更复杂的可能是页面提交的一笔数据可能要引起N个表格的更新，而这么多表格的更新过程是一种逻辑，应该有一个组件来支持。
我一直怀疑我自己对ASP.NET的了解程度，但是找来找去就是找不到页面提交数据，服务器上的业务组件对数据进行分析，然后更新到多个表这样的一个过程。
如果您知道，您不妨给我指点一下；如果您也有兴趣，大家一起讨论；共同学习，共同提高！

------解决方案--------------------
当然可以~~~~你那是三层 也就是MVC的思想 我个人对MVC架构的看法是 代码少,速度快

缺点是安全差,还有一个致命的就是 不好分工 不好修改
因为就象你说的U第人必须对数据库了解 如果一旦要修改 一般都是涉及到几层去修改

你要事物在一个模式下的话 大概思路是
接口有打开事物,关闭事物,事物回滚这3个方法(注意这个3个方法的连接对象是同一个,一个私有成员),其他的什么或者一行,获得 dataset都是一样的,只是接口的方法都必须是返回int 来看是否执行成功

然后再搞一来进行增删改查 只做增删改查 不做别的

然后逻辑层BC BC来调用那个增删改查的方法 但在这些方法外有一个事物 这个事物的连接对象和那些增删改查的方法的对象是同一个对象,BC里面有一个增删改查层的构造函数对吧 这个构造函数需要传递一个已经实例化的接口 那么增删改查的连接对象和事物的连接对象就是一个对象了
------解决方案--------------------
对于objectdatasource,基本做法是绑定到一个类上,而这个类怎么写,其实是由BLL层来决定的,所以并不只限于单表更新,比如你可以写一个类,这个类实际上是更新了两个以上表,这是不难做到的,也不难理解.但是对于主从表,从表因为是一个记录集合,而不仅是一条记录,objectdatasource是不是能支持我也没有试过,估计是不能支持的.对于这类问题,如果看一些代码,可以发现在WEB应用中,基本上都是先输入主表记录,然后再输入子表记录,而且一般都采用 "向导 "的方式,减少用户的不良体验,当然在编程上,也减少了程序的复杂度.所以一般情况下,objectdatasource也能应付.
但是如果以上的不能满足实际要求,那么objectdatasource可能应不适应了,这时肯定要自已写代码.
其实从微软的想法上,是想提供一个应用程序的框架,而这个框架,是以组件的形式出现的,你用这些组件,就会不自觉的应用上设计模式一类的东西,而你并不会感觉到这些.但这里也有问题,就是它封装的东西,从演示上看,效果非常好,但只是对一般的应用效果好,而对于复杂的应用,它就显得力不从心.所以研究.net,很多时候都在研究怎么样扩展微软提供的类库,本人以为,这样做固然能加深对控件的理解,但很多时候并无必要.再好的控件,最后其实都是生成了一堆的html,如果你有学习这些控件的功夫,也许自已也已经写出了比较适用于自已项目的新的控件.

------解决方案--------------------
“ObjectDataSource只能接受单条记录的数据，而这些数据格式又只是string，int,float等”这是不对的。这明明是GridView等控件的问题，不是数据源的问题。ObjectDataSource数据源对数据的更新、创建、缓存等都提供了框架流程，但是其过程都是使用object类型做处理对象的，没有假设过对象的细节必须有什么类型的字段或者属性。

那两个控件是asp.net2.0项目组刚刚在一两年前研发出来，而ADO.NET虽然是.Net平台的，但是其设计结构和功能可以很容易地追溯 ADO、RDO、ODBC、DAO以及更早的很多微软的数据库接口规范以及实实在在的产品，可以说微软至少15年以上的许多“代”设计精英设计出来的，每一个系统都有当时时代的技术特色。这些都是比较高级的、纯粹为关系数据库编程设计的引擎。

不过，时代在往前发展，关系数据库开始让位给更高级的数据库结构了，SOA架构之下c/s数据库编程开始显露出更多弊病了。

微软的东西比时代总是晚好几年。只是我们都用微软的东西，所以很多人觉得微软的改变很令人吃惊。而很多对软件工程早几年就有接触的人则会觉得欣喜，总算可以暂时不用去考虑放弃微软的这么流行的开发工具了。
------解决方案--------------------
实际一般都分为
DAL、BLL、Model三层，还可以扩展为IDAL等等
给你一个小例子
http://www.51aspx.com/CV/AjaxMyPage/
更多的在这里
http://www.51aspx.com/Tags/2/


------解决方案--------------------
Eddie005(♂) №.零零伍 (♂)

相对来说，在C/S应用程序里作用要大一些，作为内存中的小型数据库，可以暂存新增/修改/删除的数据，并且随时可以反悔或者批量更新到数据库；

但是，在B/S应用中意义就显得没那么大了，由于访问数据库时，在服务器中DataSet并不会保持（当然我们也不希望保持，否则每个访问站点用户都在服务器占用一片内存，吃不消），所以在B/S中很少能发挥DataSet的这一点长处~
------解决方案--------------------
分層有時候並不是那麼好做，如果系統夠大，才適用的
------解决方案--------------------
在ASP.NET中，数据的存储使用SQLDataSource、ObjectDataSource，这些DataSource实际使用SQL语句或者TableAdapter捆绑的SQL语句进行数据的访问和更新，并没有打包的概念。

也可以使用DataSet的。
------解决方案--------------------
我比较喜欢用ObjectDataSource,它确实是方便,而且开发的速度很快,代码少.
目前我有一个自己开发的代码生成器,它的功能非常强大,是要根据您输入的某个数据库的表就可以建立起模块,然后从数据链接层-> 业务层-> 表示层.一层一层的自动生成cs文件或aspx文件,而且在表示层能够实现添加,修改,列表查找,和删除.根本就不用怎么写代码,非常傻瓜.