ASP.NET做三层（或者多层）的架构讨论

Question

我以前使用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的了解程度，但是找来找去就是找不到页面提交数据，服务器上的业务组件对数据进行分析，然后更新到多个表这样的一个过程。
如果您知道，您不妨给我指点一下；如果您也有兴趣，大家一起讨论；共同学习，共同提高！

Answer 1

一个动作引起N的表的更新 那就会有N的方法对吧
那么你要确保安全性的话 在架构方面 可以在这N的方法外整个加上一个事物
如果其中的一个方法出错 则全部回滚~~~这样做的时候 你就要使这N个方法的连接对象是同一个连接对象才能做到一个菜鸟的建议 仅供参考

Answer 2

wangzhaoli1982：谢谢您参与讨论。N个表的更新是需要一个整体的事务环境，这个应该在业务对象中封装的。从客户端一端看，既看不到有几个表将要更新，也看不到是否有事务出现，一切都是不透明的。客户段只是提交数据，然后得知是否提交成功。像目前的ASP.NET的开发模式，前台页面工作者必须对数据库很清楚的。最致命的是，没法多个表更新在一个事务模式下。

Answer 3

当然可以~~~~你那是三层 也就是MVC的思想 我个人对MVC架构的看法是 代码少,速度快缺点是安全差,还有一个致命的就是 不好分工 不好修改
因为就象你说的U第人必须对数据库了解 如果一旦要修改 一般都是涉及到几层去修改你要事物在一个模式下的话 大概思路是
接口有打开事物,关闭事物,事物回滚这3个方法(注意这个3个方法的连接对象是同一个,一个私有成员),其他的什么或者一行,获得 dataset都是一样的,只是接口的方法都必须是返回int 来看是否执行成功然后再搞一来进行增删改查 只做增删改查 不做别的然后逻辑层BC BC来调用那个增删改查的方法 但在这些方法外有一个事物 这个事物的连接对象和那些增删改查的方法的对象是同一个对象,BC里面有一个增删改查层的构造函数对吧 这个构造函数需要传递一个已经实例化的接口 那么增删改查的连接对象和事物的连接对象就是一个对象了

Answer 4

UI的人就调用BC封状好的方法就可以 他就不需要了解数据库BC的人就管理逻辑 这里BC的人是最需要技术好的人在的一般的人就做增删改查就可以了

Answer 5

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

Answer 6

可能我没说清楚。这里我们也不比较各种模式的差异。我现在在ASP.NET上面就要实现MVC的模式。
而这种模式使用现成的GridView、DetailsList和FormList这些控件。这些控件使用DataSource控件，而DataSource控件只能连接数据访问对象（TableAdapter对象，也可以访问业务对象，但是这种业务对象的接口太单一）现在要搞清楚的是，ASP.NET中是怎么一个过程来实现多层架构呢？

Answer 7

lnwuyaowei(风可以追我) ：欢迎您参加讨论！首先一个问题，如果采用向导方式，先输入主表信息再输入明细表信息。如果是分开保存的话，则可能维护明细不能为空的逻辑。如果是同时提交的话，ASP.NET好像不支持。其次，您说的对的，ASP.NET这些控件实际可能就限定了某中模式，要超出这种模式之外显得力不从心。我也不是想扩展这些组件，我只是想知道如何用现在的组件来搭建我想要的模式。虽然我目前的认识ASP.NET做不到，但是我想微软这么大公司不会这个问题没想到吧？而且这里还没有讲到分布式问题呢，如果提交的数据当中，A数据要保存到另外网络中的计算机，B数据要保存在本地计算机中，这个又如何做到呢？
欢迎大家继续讨论！

Answer 8

qufo：欢迎您参加讨论！存储过程是不能解决此类问题的。存储过程也可以实现企业逻辑，但这里并不是如何表达企业逻辑的问题。而是页面如何与业务对象衔接的问题。因此ObjectDataSource只能接受单条记录的数据，而这些数据格式又只是string，int,float等，不能是一个DataSet。

Answer 9

“ObjectDataSource只能接受单条记录的数据，而这些数据格式又只是string，int,float等”这是不对的。这明明是GridView等控件的问题，不是数据源的问题。ObjectDataSource数据源对数据的更新、创建、缓存等都提供了框架流程，但是其过程都是使用object类型做处理对象的，没有假设过对象的细节必须有什么类型的字段或者属性。那两个控件是asp.net2.0项目组刚刚在一两年前研发出来，而ADO.NET虽然是.Net平台的，但是其设计结构和功能可以很容易地追溯 ADO、RDO、ODBC、DAO以及更早的很多微软的数据库接口规范以及实实在在的产品，可以说微软至少15年以上的许多“代”设计精英设计出来的，每一个系统都有当时时代的技术特色。这些都是比较高级的、纯粹为关系数据库编程设计的引擎。不过，时代在往前发展，关系数据库开始让位给更高级的数据库结构了，SOA架构之下c/s数据库编程开始显露出更多弊病了。微软的东西比时代总是晚好几年。只是我们都用微软的东西，所以很多人觉得微软的改变很令人吃惊。而很多对软件工程早几年就有接触的人则会觉得欣喜，总算可以暂时不用去考虑放弃微软的这么流行的开发工具了。

Answer 10

实际一般都分为
DAL、BLL、Model三层，还可以扩展为IDAL等等
给你一个小例子
http://www.51aspx.com/CV/AjaxMyPage/
更多的在这里
http://www.51aspx.com/Tags/2/

Answer 11

我不说具体问题，只说方向：我说“关系数据库开始让位给更高级的数据库结构了”是什么意思呢？我在前几天举过两个例子：驾驶员 per=new 驾驶员("张三",28,"110109888981");
汽车 car=new 宝马("AD382323",per);
事故 xx=new 撞车事故();
xx.car=car;
.....
using(Domain dm=new LocalDatabase())
{
  xx.Save();
}这样就把整个故事保存进数据库了，根本不需要像关系数据库那样去创建表、索引、约束之类的东西。处理并发、缓存、搜索的性能比纯种的关系数据库通常都快10倍。asp.net中的webService也是类似，服务器上的类型更新可以自动部署到所有客户程序中。过去，所谓“三层”较多地谈软件接口、ORM 等如何如何，其实程序员光说不练也能吃得开。现在，慢慢地终于新的分布式系统架构可能要逼着程序员必须把数据库尽量简单化。包括Oracle、DB2等都在将应用开发平台转向上面程序那种面向对象的界面，关系数据库的那些繁琐的分析设计和维护技术会被人淡忘。

Answer 12

sp1234：欢迎您参加讨论！您说的没错，objectDataSource可以接受Object类型，也可以接受DataSet类型，只是GridView这些控件不能支持明细表的关联。不好意思，下面这段话：
“不过，时代在往前发展，关系数据库开始让位给更高级的数据库结构了，SOA架构之下c/s数据库编程开始显露出更多弊病了。微软的东西比时代总是晚好几年。只是我们都用微软的东西，所以很多人觉得微软的改变很令人吃惊。而很多对软件工程早几年就有接触的人则会觉得欣喜，总算可以暂时不用去考虑放弃微软的这么流行的开发工具了。”我看不大懂，见谅见谅。微软的IDE的确是不错的，功能很强大。我想请教你一下，一般大型的业务管理网站是如何设计的呢？

Answer 13

应该更准确一点：xx.Save();  -->  dm.Save(xx);
  或者：    -->  xx.Save(dm);实现方法不同，但是同一个意思，把对象丢进永久存储服务器里。

Answer 14

sp1234：您的例子分为两方面，第一方面像驾驶员，汽车这些都属于实体对象，事故则属于复合类型的实体对象，这种分析方法当然是对的，在目前的软件开发中也是如此。如果把这些信息保存起来，是关系数据库也好，XML也好，只是一个数据存储的方式。所以，您认为“根本不需要像关系数据库那样去创建表、索引、约束之类的东西。处理并发、缓存、搜索的性能比纯种的关系数据库通常都快10倍”并不能完全赞同。实际上，如果能够证明对象数据库比关系数据库性能更优越的话，您的想法是正确的。
第二方面“慢慢地终于新的分布式系统架构可能要逼着程序员必须把数据库尽量简单化”，数据库简单化一直是大家追求的目标，不过即使到现在以及将来，分布式系统并不是让数据库更加简单，而是对各个系统的集成称为可能，各个内容提供商提供的服务进行集成。总之，分布式架构的产生不是因为数据库的存储原因而产生的。
我们现在谈的已经脱离我原来想知道的有关ASP.NET的问题。上面也仅是我个人从事软件行业而来一些想法，如有不妥敬请批评指正。

Answer 15

iloveaspx：欢迎您参加讨论。您给我的资料我正在看……

Answer 16

bakers(baker)：欢迎您参加讨论！您说的没错，其实何止复用，更精确的可以说方便！一切为了方便！

Answer 17

Eddie005(♂) №.零零伍 (♂) 相对来说，在C/S应用程序里作用要大一些，作为内存中的小型数据库，可以暂存新增/修改/删除的数据，并且随时可以反悔或者批量更新到数据库；但是，在B/S应用中意义就显得没那么大了，由于访问数据库时，在服务器中DataSet并不会保持（当然我们也不希望保持，否则每个访问站点用户都在服务器占用一片内存，吃不消），所以在B/S中很少能发挥DataSet的这一点长处~

Answer 18

在ASP.NET中，数据的存储使用SQLDataSource、ObjectDataSource，这些DataSource实际使用SQL语句或者TableAdapter捆绑的SQL语句进行数据的访问和更新，并没有打包的概念。也可以使用DataSet的。

Answer 19

我比较喜欢用ObjectDataSource,它确实是方便,而且开发的速度很快,代码少.
    目前我有一个自己开发的代码生成器,它的功能非常强大,是要根据您输入的某个数据库的表就可以建立起模块,然后从数据链接层->业务层->表示层.一层一层的自动生成cs文件或aspx文件,而且在表示层能够实现添加,修改,列表查找,和删除.根本就不用怎么写代码,非常傻瓜.
     其中在业务层我就是在每个模块的方法中写5个函数,分别是:增,删,改,查,数.每个函数都为ObjectDataSource做一个接口.
     页面就用GridView做查找列表和删除,FormView做添加和修改,2个控件都是绑定ObjectDataSource的

Answer 20

这么多人啊，大家好，来不及欢迎大家了，随便坐！
zzmsl：您说的没错！服务器为每个客户端保持一份DataSet的Session的成本是挺大的。

Answer 21

Eri(NULL)：如何使用DataSet？请给我详细讲一讲。我曾做过一个测试，我没有使用ObjectDataSource，我从业务对象获取数据称为为DataSet，然后用这个包含数据的DataSet与GridView关联并绑定，能正常显示。然后在GridView的几个Item事件中写代码，我写了Delete事件，能够删除（有一个问题，下面讲）。这样一个来回，我知道其实根本不用ObjectDataSource，就是一个DataSet和GridView这些数据感知控件直接关联就可以了。只是这里有一个，GridView这些Item的事件发生后，怎么取当前GridView行的数据呢？如果这个问题可以解决，那么三层也就可以实现了。浪费服务器内存来保存DataSet也是没有办法的事情。删除事件中有一个问题，事件参数e,e.RowIndex是指视图上的索引，不是DataTable中的索引。所以如果直接使用DataTable.Rows[e.RowIndex].Delete()将不能删除指定的行。这个话题可以接下去吗？

Answer 22

终于用了一下ObjectDataSource，说什么好呢？
我感觉这么发展下去，用不了多久，程序员可能就失业了。显示表里的数据，根本就不用写代码。拽两个控件，电几下鼠标就可了。一点难度都没有了呀。埃，怎么活呀。

Answer 23

不好意思，发错地方了。to:heshengjie(何必累) vs2003的时候，我是把主键放在DataGrid的第一列列保存的，这样在删除的时候就可以找到了。

Answer 24

欢迎您，jyk！
您说的也是办法的一种，但肯定不是正统的办法。ObjectDataSource的功能并不强大，我认为。如果可以使用SQLDataSource的话，一般都会用它。ObjectDataSource既然不支持真正的业务对象，作用类似SQLDataSource。也许是我的误解，但是到现在我还真没找到方法，这不能不说一个缺陷，无论实际是可以做到，还是微软的介绍欠缺。

Answer 25

我习惯放在第一列，正统的是方在DataGrid的DataKey里面把。（好像是叫这个名字）。

Answer 26

to jyk
我好久没用2003了,我知道asp.net2.0的GridView里有个DataKey
顺便流个脚印

Answer 27

***************************************************
驾驶员 per=new 驾驶员("张三",28,"110109888981");
汽车 car=new 宝马("AD382323",per);
事故 xx=new 撞车事故();
xx.car=car;
.....
using(Domain dm=new LocalDatabase())
{
xx.Save();
}
*******************************************************
超强

Answer 28

楼上的用上NHiberate了，快……

Answer 29

不好意思在说一句啊， to interboy 03也有DataKeyField的

Answer 30

这个帖子时间也久了，对于ASP.NET用来开发大型网站，其中对数据提交的支持并不如Java。谁如果知道有好的解决方案，不妨在此贴说明一下，让大伙也学习学习！。分少人多，大家见谅，我想大家在一起讨论也是为了共同进步而不是为了这些积分。再次感谢大家！

Answer 31

FrameCountry是采用.Net的开发平台，专注于数据库访问层功能的架构系统，为用户提供便捷、规范、强大的功能，提升开发效率。 FrameCountry特点
1. 便捷开发：封装、整合数据库操作方式，让开发人员摆脱数据库的约束；
2. 规范开发：依据多层设计原理，明晰人员分工，提高程序可读性；
3. 记录运行情况：开发人员依据记录了解系统详情，方便调试排错；
4. 多样数据库连接：实现多种数据库连接方式，对开发人员透明化数据库连接，使其只关注上层程序，同时降低数据库转换、升级工作量，目前实现Access2000、SQLServer2000两种数据库，日后逐步增加关系型数据库连接配置；
5. 整合有效函数：对开发中其它的有用的、常用的函数进行整理，简单调用实现；访问http://blog.csdn.net/lizheng82

Answer 32

我一直在做多层架构中数据访问层的研究，自己写了一个架构程序，感兴趣的朋友可以去看看
http://blog.csdn.net/lizheng82

Answer 33

三层结构和oracle是怎样的一个关系啊？