ASP[1].NET中的“三层结构”

ASP.NET中的“三层结构”“三层结构”是什么？“三层结构”一词中的“三层”是指：“表现层”、“中间业务层”、“数据访问层”。其中：表现层：位于最外层（最上层），离用户最近。用于显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面。中间业务层：负责处理用户输入的信息，或者是将这些信息发送给数据访问层进行保存，或者是调用数据访问层中的函数再次读出这些数据。中间业务层也可以包括一些对“商业逻辑”描述代码在里面。数据访问层：仅实现对数据的保存和读取操作。数据访问，可以访问数据库系统、二进制文件、文本文档或是XML文档。对依赖方向的研究将是本文的重点，数值返回方向基本上是没有变化的。在一个如果只以分层的设计角度看，Duwamish7要比PetShop3.0复杂一些！而如果较为全面的比较二者，PetShop3.0则显得比较复杂。但我们先不讨论这些，对PetShop3.0和Duwamish7的研究，并不是本文的重点。现在的问题就是：既然“三层结构”已经被分派到各自的项目中，那么剩下来的项目是做什么的呢？例如PetShop3.0中的“Model”、“IDAL”、“DALFactory”这三个项目，再例如Duwamish7中的“Common”项目，还有就是在Bincess.CN彬月论坛中的“Classes”、“DbTask”、这两个项目。它们究竟是做什么用的呢？对“三层结构”的深入理解——从一家小餐馆说起一个“三层结构”的Web应用程序，就好象是一家小餐馆。n表现层，所有的.aspx页面就好像是这家餐馆的菜谱。n中间业务层，就像是餐馆的服务生。n数据访问层，就像是餐馆的大厨师傅。n而我们这些网站浏览者，就是去餐馆吃饭的吃客了……我们去一家餐馆吃饭，首先得看他们的菜谱，然后唤来服务生，告诉他我们想要吃的菜肴。服务生记下来以后，便会马上去通知大厨师傅要烹制这些菜。大厨师傅收到通知后，马上起火烧菜。过了不久，服务生便把一道一道香喷喷的、热气腾腾的美味端到我们的桌位上——而我们访问一个基于asp.net技术的网站的时候，首先打开的是一个aspx页面。这个aspx页面的后台程序会去调用中间业务层的相应函数来获取结果。中间业务层又会去调用数据访问层的相应函数来获取结果。为什么需要“三层结构”？——初探，就从数据库的升迁开始一个站点中，访问数据库的程序代码散落在各个页面中，就像夜空中的星星一样繁多。这样一动百动的维护，难度可想而知。最难以忍受的是，对这种维护工作的投入，是没有任何价值的……有一个比较好的解决办法，那就是将访问数据库的代码全部都放在一个程序文件里。这样，数据库平台一旦发生变化，那么只需要集中修改这一个文件就可以了。我想有点开发经验的人，都会想到这一步的。这种“以不变应万变”的做法其实是简单的“门面模式”的应用。如果把一个网站比喻成一家大饭店，那么“门面模式”中的“门面”，就像是饭店的服务生，而一个网站的浏览者，就像是一个来宾。来宾只需要发送命令给服务生，然后服务生就会按照命令办事。至于服务生经历了多少辛苦才把事情办成？那个并不是来宾感兴趣的事情，来宾们只要求服务生尽快把自己交待事情办完。我们就把ListLWord.aspx.cs程序就看成是一个来宾发出的命令，而把新加入的LWordTask.cs程序看成是一个饭店服务生，那么来宾发出的命令就是：“给我读出留言板数据库中的数据，填充到DataSet数据集中并显示出来！”而服务生接到命令后，就会依照执行。而PostLWord.aspx.cs程序，让服务生做的是：“把我的留言内容写入到数据库中！”而服务生接到命令后，就会依照执行。这就是TraceLWord2！可以在CodePackage/TraceLWord2目录中找到——把所有的有关数据访问的代码都放到LWordTask.cs文件里，LWordTask.cs程序文件如下：usingSystem;usingSystem.Data;usingSystem.Data.OleDb;//需要操作Access数据库usingSystem.Web;namespaceTraceLWord2{///summary///LWordTask数据库任务类////summarypublicclassLWordTask{//数据库连接字符串privateconststringDB_CONN=@PROVIDER=Microsoft.Jet.OLEDB.4.0;DATASource=C:\DbFs\TraceLWordDb.mdb;///summary///读取数据库表LWord，并填充DataSet数据集////summary///paramname=ds填充目标数据集/param///paramname=tableName表名称/param///returns记录行数/returnspublicintListLWord(DataSetds,stringtableName){stringcmdText=SELECT*FROM[LWord]ORDERBY[LWordID]DESC;OleDbConnectiondbConn=newOleDbConnection(DB_CONN);OleDbDataAdapterdbAdp=newOleDbDataAdapter(cmdText,dbConn);intcount=dbAdp.Fill(ds,tableName);returncount;}///summary///发送留言信息到数据库////summary///paramname=textContent留言内容/parampublicvoidPostLWord(stringtextContent){//留言内容不能为空if(textContent==null||textContent==)thrownewException(留言内容为空);stringcmdText=INSERTINTO[LWord]([TextContent])VALUES(@TextContent);OleDbConnectiondbConn=newOleDbConnection(DB_CONN);OleDbCommanddbCmd=newOleDbCommand(cmdText,dbConn);//设置留言内容dbCmd.Parameters.Add(newOleDbParameter(@TextContent,OleDbType.LongVarWChar));dbCmd.Parameters[@TextContent].Value=textContent;try{dbConn.Open();dbCmd.ExecuteNonQuery();}catch{throw;}finally{dbConn.Close();}}}}如果将数据库从Access2000修改为SQLServer2000，那么只需要修改LWordTask.cs这一个文件。如果LWordTask.cs文件太大，也可以把它切割成几个文件或“类”。如果被切割成的“类”还是很多，也可以把这些访问数据库的类放到一个新建的“项目”里。当然，原来的ListLWord.aspx.cs文件应该作以修改，LWord_DataBind函数被修改成：privatevoidLWord_DataBind(){DataSetds=newDataSet();(newLWordTask()).ListLWord(ds,@LWordTable);m_lwordListCtrl.DataSource=ds.Tables[@LWordTable].DefaultView;m_lwordListCtrl.DataBind();}原来的PostLWord.aspx.cs文件也应作以修改，Post_ServerClick函数被修改成：privatevoidPost_ServerClick(objectsender,EventArgse){//获取留言内容stringtextContent=this.m_txtContent.Value;(newLWordTask()).PostLWord(textContent);//跳转到留言显示页面Response.Redirect(ListLWord.aspx,true);}从前面的程序段中可以看出，ListLWord.aspx.cs和PostLWord.aspx.cs这两个文件已经找不到和数据库相关的代码了。只看到一些和LWordTask类有关系的代码，这就符合了“设计模式”中的一种重要原则：“迪米特法则”。“迪米特法则”主要是说：让一个“类”与尽量少的其它的类发生关系。在TraceLWord1中，ListLWord.aspx.cs这个类和OleDbConnection及OleDbDataAdapter都发生了关系，所以它破坏了“迪米特法则”。利用一个“中间人”是“迪米特法则”解决问题的办法，这也是“门面模式”必须遵循的原则。下面就引出这个LWordTask门面类的示意图：ListLWord.aspx.cs和PostLWord.aspx.cs两个文件对数据库的访问，全部委托LWordTask类这个“中间人”来办理。利用“门面模式”，将页面类和数据库类进行隔离。这样就作到了页面类不依赖于数据库的效果。以一段比较简单的代码来描述这三个程序的关系：publicclassListLWord{privatevoidLWord_DataBind(){(newLWordTask()).ListLWord(...);}}publicclassPostLWord{privatevoidPost_ServerClick(objectsender,EventArgse){(newLWordTask()).PostLWord(...);}}publicclassLWordTask{publicDataSetListLWord(DataSetds)...publicvoidPostLWord(stringtextContent)...}应用中间业务层，实现“三层结构”前面这种分离数据访问代码的形式，可以说是一种“三层结构”的简化形式。因为它没有“中间业务层”也可以称呼它为“二层结构”。一个真正的“三层”程序，是要有“中间业务层”的，而它的作用是连接“外观层”和“数据访问层”。换句话说：“外观层”的任务先委托给“中间业务层”来办理，然后“中间业务层”再去委托“数据访问层”来办理……那么为什么要应用“中间业务层”呢？“中间业务层”的用途有很多，例如：验证用户输入数据、缓存从数据库中读取的数据等等……但是，“中间业务层”的实际目的是将“数据访问层”的最基础的存储逻辑组合起来，形成一种业务规则。例如：“在一个购物网站中有这样的一个规则：在该网站第一次购物的用户，系统为其自动注册”。这样的业务逻辑放在中间层最合适：在“数据访问层”中，最好不要出现任何“业务逻辑”！也就是说，要保证“数据访问层”的中的函数功能的原子性！即最小性和不可再分。“数据访问层”只管负责存储或读取数据就可以了。在新TraceLWord3中，应用了“企业级模板项目”。把原来的LWordTask.cs，并放置到一个单一的项目里，项目名称为：AccessTask。解决方案中又新建了一个名称为：InterService的项目，该项目中包含一个LWordService.cs程序文件，它便是“中间业务层”程序。ASP.NETWeb应用程序解决方案中，并不是说有aspx文件、有dll文件、还有数据库，就是“三层结构”的Web应用程序，这样的说法是不对的。也并不是说没有对数据库进行操作，就不是“三层结构”的。其实“三层结构”是功能实现上的三层。例如，在微软的ASP.NET示范实例“Duwamish7”中，“表现层”被放置在“Web”项目中，“中间业务层”是放置在“BusinessFacade”项目中，“数据访问层”则是放置在“DataAccess