C多层应用架构

Duwamish架构分析篇Duwamish是Microsoft提供ー个企业级的分布式系统架构,如果开发企业级的分布式系统,可以模仿这种架构,如果是开发ー些简单的系统,则完全可以简化。以前也学习过Duwamish范例,只是发现不同时间,不同经历,有不同的体会。正如卢彦所说的一样:通过研究Duwamish示例,高手能够领悟到.Net应用架构的设计思想,低手能够学习到Net的编程技巧,实在是老少皆宜。因此,这里再次学习并体验一次Duwamish范例。1,Duwamish7.0结构分为四个逻辑层(FROMMSDN)：Web层—PresentationWeb层为客户端提供对应用程序的访问。这ー层是作为Duwamish.sin解决方案文件中的Web项目实现的。Web层由ASP.NETWeb窗体和代码隐藏文件组成。Web窗体只是用HTML提供用户操作,而代码隐藏文件实现各种控件的事件处理。业务外观层—BusinessFacade业务外观层为Web层提供处理帐户、类别浏览和购书的界面。这ー层是作为Duwamish.sln解决方案文件中的BusinessFacade项目实现的。业务外观层用作隔离层,它将用户界面与各种业务功能的实现隔离开来。除了低级系统和支持功能之外,对数据库服务器的所有调用都是通过此程序集进行的。业务规则层ーBusinessRules业务规则层是作为Duwamish.sln解决方案文件中的BusinessRules项目实现的,它包含各种业务规则和逻辑的实现。业务规则完成如客户帐户和书籍订单的验证这样的任务。数据访问层ーDataAccess数据访问层为业务规则层提供数据服务。这ー层是作为Duwamish.sln解决方案文件中的DataAccess项目实现的。除了上述四个逻辑层外,Duwamish7.0还包含封装在Duwamish.sln解决方案文件中的Common项目内的共享函数。“通用"（Common）层包含用于在各层间传递信息的数据集。Common项目还包含Duwamish.sln解决方案文件中的SystemFramework项目内的应用程序配置和跟踪类。

2,各个逻辑层之间的关系图(FROMMSDN)2,各个逻辑层之间的关系图(FROMMSDN)及其调用Sequeance图示例:数・库〇SQLServer下面是Categories.aspxweb页面获取Category的Description的整个调用过程。(1)实例化Productsystem对象(2)调用Productsystem的GetCategories。方法(3)检测参数的合法性(4)仓リ建Categories::DataAccess对象实例(5)返回上述对象(6)调用Categories::DataAccess对象的GetCategories()方法(7)仓リ建CategoryData::Common对象实例(8)返回上述对象(9)返回CategoryData:zCommon对象实例,该实例中已经包含了需要的数据(10)返回CategoryData::Common对象实例给web/Client端(11)检测数据的合法性(12)读取并显示结果:Category的Descriptionr一 ！1 |1Createaninstanceobjel>uJ2:GetCategoriesQ；1:t3:CheckCjnditionQg1ProductSvstem二BusinessFacadeADDlicationAssert二SystemFrameworkCategories二DataAccessCateqories.aspx.es二CateqorvData::Cateqories.aspx.es二CateqorvData::4:Createaninstanceol蟻Ct*5:Return^Categories二DataAccessobject7:Createaninstanceobject6:GetCategoriesQ10:: 甘9:ReturnCategoryDataobject十10:: 甘9:ReturnCategoryDataobject十 :8:ReturnCate^oryDataobjectReturnCategoryDataobject： 1：1：CheckConditionQ12:ReadanddisplaythedescriptionfortheCategory: :尸［；：］ 1 1 • i 1 KAnothercallingprocessonProductsystem.GetCategoryltemsOisalmostthesamewiththeabowprocedure.TheonlydifferencesareusingBooks::DataAccessandBookData::Commonclasses,insteadofCategories::DataAccessandBookData::Commaonclasses.SystemFramework项目包含ー些application需要的配置参数,ApplicationLog日志类和ApplicationAssert参数校验类。SystemFramework项目为所有其他的项目所引用。Common项目包含了用于在各层间传递信息的数据集,如上述的CategoryData继承System.Data.DataSet,既不是所谓的typedDataSet,也不是一般的DataSet,不过简单实用,这是基于.NetRemoting开发分布式系统用来tier与tier之间交互数据的ー种方法。Common项目也被其他的项目引用,SystemFramework项目除外。BusinessFacade项目中所有的Classes继承MarshalByRefObjectclass,显然是让准备将BusinessFacadetier部署为Remote〇bjects。不过,实际上默认这里并没有将其部署为RemoteObjects,Web层仍然调用本地对象（《Duwamish部署方案篇》将分析这个问题）。3,Summary在开发基于.NetFramework企业级分布式系统时,上述架构值得推荐,但也并非完美无暇,实际上存在ー些值得改进的地方。显然,不可能一个范例适合所有的实际情况么,要求太苛刻了。其实,EnterpriseSamples中的另外一个范例FitchandMather7.0,其架构和Duwamish就有些不同了。

如果是开发本地的系统,就不要模仿Duwamish架构（看看上面获取Category的Description调用过程就知道了,太费劲。）,如BusinessFacade和BusinessRules中Classes应采用fine-grainedinterface设计,层与层之间的交互参数也不必全部采用DataSet,适当的时候采用setter/getter就可以了,这样不仅可以提高开发效率,而且有助于提咼performance,maintainabilityandreusabilityoDuwamish部署方案篇Duwamish部署方案篇Duwamish7.0支持两种多计算机部署方案。非分布式部署方案在一台Web主机上部署Web层、业务外观、业务规则和数据访问层,但可以在群集间复制该Web主机以达到负载平衡。分布式方案在单独的服务器上部署特定的组件。例如,业务外观、业务规则和数据访问层可能位于独立于Web主机的服务器上。在实际部署中数据库服务器通常位于单独的计算机上。1S非分布式部署方案

在一台Web主机上部署Web层、业务外观、业务规则和数据访问层,然后通过软件（如ApplicationCenter2000）或硬件来实现网络场（WebFarm）内各个WebServer的负载平衡。在本机默认安装Duwamish7.0时,是采用非分布式部署万案。2s分布式部署方案使用.NETFramework远程处理技术将应用程序分布到多台计算机中。简单而言,就是IISWebServer和ApplicationServer分离,其中Web层（包括SystemFramework和Common项目）部署在IISWeb上,BusinessFacde/BusinessRules/DataAccess（包括SystemFramework和Common项目）ー起部署在ApplicationServer±〇ApplicationCenterNLB群集NIC110.2.2.xxNIC210.2.3.XX管理

通信量HS群集控制器（计宜机A）NIC310.2.4.xxxx防火墙xxNIC110.2.2.xx 管理NIC2通信量10.2.3.XXHS群集成员（计苴机B）NIC310.2.4.xxNIC110.2.2.xxZApplicationCenterNLB群集NIC110.2.2.xxNIC210.2.3.XX管理

通信量HS群集控制器（计宜机A）NIC310.2.4.xxxx防火墙xxNIC110.2.2.xx 管理NIC2通信量10.2.3.XXHS群集成员（计苴机B）NIC310.2.4.xxNIC110.2.2.xxZDuwamishNIC2恢・10.2.3.XX1^HS料族成员（计算机C）组件:WebSystemFrameWorkCommonNIC310.2.4.XX10.2.4.xx防火墙NIC110.2.5.xxNIC1xxNIC110.2.5.xxNIC210.2.6.XX管理

通信量NIC210.2.6.XX管理

通信量集sas（计算机X）NIC310.2.7.XX（计算机Y）NIC310.2.7.XXxx集^（计宜机Z）uwamish组件:BusinessFacadeBusinessRulesDataAccessSystemFrameworkCommonNIC310.2.7.xx.NET远程处理:HTTP/二进制

10.2.5.XXApplicationCanterNLB群集10.2.7.XX©SQLServerDuwamish7.0使用HTTP/二进制而不是HTTP/S0APo使用HTTP的决定基于要通过端口80上的防火墙的要求。使用二进制而不是SOAP的决定基于性能上的考虑。对于大的数据块,二进制的性能优于SOAPo因此,如果要传递大的数据块（例如,数组、数据集或数据表）,则使用二进制格式化程序。如果要传递小的数据块,则选择使用SOAP还是二进制格式化程序是无关紧要的。传递整数时两者的性能都很好。3,如何将Duwamish7.0部署为基于.NetRemoting的分布式系统下面采用Microsoft提供的Deploytool工具自动进行（其实手工也很方便）：C:\ProgramFilesXMicrosoftVisualStudio.NET2003\EnterpriseSamplesXDuwamish7.0CS>deploytooldeployRemoteMachine=localhostpath=MC:\ProgramFilesXMicrosoftVisualStudio.NET2003XEnterpriseSamplesXDuwamish7.0CS\Duwamish7_Remote,,在commandline窗口输入上述命令行代码。[10/29/20046:43:43AM]CreatingdirectoryC:\ProgramFilesXMicrosoftVisualStudio.NET2003\EnterpriseSamplesXDuwamish7.0CS\Duwamish7_RemoteonW1MIS38[10/29/20046:43:43AM]StoppingallinternetservicesonW1MIS38[10/29/20046:43:59AM]DeployingDuwamish7BusinessFacadeonW1MIS38[10/29/20046:43:59AM]CreatingwebsiteonW1MIS38[10/29/20046:44:00AM]Generatingremotingconfigurationfiles[10/29/20046:44:00AM]StartingallinternetservicesonW1MIS38[10/29/20046:44:02AM]StartingDefaultWebSiteonW1MIS38[10/29/20046:44:02AM]Deploymentsuccessful运行结果:(1)在IIS创建中创建WebApplication(Duwamish7_Facade),本地路径为:C:\ProgramFilesXMicrosoftVisualStudio.NET2003\EnterpriseSamplesXDuwamish7.0CS\Duwamish7_RemoteXweb作为RemoteServer端,Bin目录下是BusinessFacde/BusinessRules/DataAccess层(包括SystemFramework和Common项目)DLL文件。其中web.config文件中包含所有RemoteObjects的配置,如<wellknownmode="Singleton"type="Duwamish7.BusinessFacade.Productsystem,Duwamish7.BusinessFacade"objectUri="ProductSystem.rem"/>Web层创建remotingclient.cfg配置文件,对ApplicationServer而言,Web层相当与Client端。remotingclient.cfg配置文件中包含formatter的设置(binary),选择二进制格式化程序来序列化消息,注意是出于性能的考虑。Webapplication加载remotingclient.cfg配置文件Webapplication在global.asax文件包括如下代码,在Application_OnStart事件中加载Retmoting配置文件。voidApplication_OnStart()Applicationconfiguration.OnApplicationStart(Context.Server.MapPath(Context.Request.ApplicationPath))；stringconfigPath=Path.Combine(Context.Server.MapPath(Context.Request.ApplicationPath),,,remotingclient.cfgu);if(File.Exists(configPath))RemotingConfiguration.Configure(configPath)；)其中前面代码Applicationconfiguration.〇nApplicationStart。是调用Duwamish7.SystemFramework.ApplicaitonConfiguration的〇nApplicationStart。方法,用来初始化applicationroot和读取web.config中的配置信息(将在《Duwamish代码分析篇》中进行具体分析)。Duwamish代码分析篇Duwamish代码分析篇Writtenby:RickieLeeNov.02,2004继续前面的2篇POSTWuwamish架构分析篇》和Wuwamish部署方案篇》,这里在代码层次上分析Duwamish7.0范例,主要目的是解析Duwamish范例中值得推荐的编码风格和提炼出可以重用的代码或Classo1,读取配置文件类ーSystemFrameworkXApplicationConfiguration.csApplicationconfiguration类用来读取web.config文件中自定义section的配置信息,初始化一些基本设置。Applicationconfiguration类实现IconfigurationSectionHandler接口,并需要实现[C#]objectCreate(objectparent,objectconfigContext,XmlNodesection)方法,以分析配置节的XMLo返回的对象被添加到配置集合中,并通过GetConfig访问。部分代码片段解释:CodeSnippet1—Applicationconfiguration.OnApplicationStart。方法publicstaticvoidOnApplicationStart(StringmyAppPath){appRoot=myAppPath;System.Configuration.Configurationsettings.GetConfig("Applicationconfiguration");System.Configuration.Configurationsettings.GetConfig("DuwamishConfiguration");System.Configuration.Configurationsettings.GetConfig("SourceViewer");)Configurationsettings类还提供了一个公共方法ConfigurationSettings.GetConfig()用于返回用户定义的配置节的配置设置,传入的参数sectionname,如"ApplicationConfiguration",表示要读取的配置节。NameValueCollectionnv=newNameValueCollection();〃实例化NameValueCollection类对象nv=(NameValueCollection)ConfigurationSettings.GetConfig("ApplicationConfiguration");〃返回用户定义的配置节的设置returnnv["SystemFramework.Tracing.Enabled"].ToString()；〃返回特定键值,如SystemFramework.Tracing.Enabled不过,Configurationsettings.GetConfig。方法在调用时,自动调用Create。方法,可以看到Applicationconfiguration.Create。方法正是用来读取指定section的配置,并初始化设置参数。Global.asax的ApplicationOnStart事件处理程序向SystemFramework的Applicationconfiguration类OnApplicationStart方法发出调用,正是上述的代码片断。CodeSnippet2—Global.asax中Application_OnStart()方法voidApplication_OnStart(){AppHcationConfiguration.OnApplicationStart(Conlext.Server.MapPath(Context.Request.ApplicationPath))；stringconfigPath=Path.Combine(Context.Server.MapPath(Context.Request.ApplicationPath),"remotingclient.cfg");if(File.Exists(configPath))RemotingConfiguration.Configure(configPath);)该方法肩负二大任务:(1)调用AppHcationConfiguration.OnApplicationStart。方法,并传入application的根目录(RootDirectory)〇(2)检测Client端的remoting配置文件是否存在（其实是webserver端）,如果存在,则读取并初始化remoting配置信息,如配置通道Channel等等,详见《Duwamish部署方案篇》。2t读取web.config中Duwamish相关的ー些配置ーCommonXDuwamishConfiguration.csCommonXDuwamishConfiguration.cs也实现IconfigurationSectionHandler接口,与SystemFrameworkXApplicationConfiguration.cs类オ目似。DuwamishConfiguration配置节包括如下ー些配置信息:Databaseconnectionstring（Database连接串）Duwamish.DataAccess.Connectionstring,是否允许页面缓存Duwamish.Web.EnablePageCache,页面缓存过期时间Duwamish.Web.PageCacheExpiresInSeconds,是否允许SSL连接Duwamish.Web.EnableSsl等等。如上所述,调用DuwamishConfigurationClass是由SystemFrameworkXApplicationConfiguration.cs的〇nApplicationStart()方法完成的:System.Configuration.Configurationsettings.GetConfig("DuwamishConfiguration");看看页面缓存配置在webpage中如何使用的(web'book.aspx.cs文件为例)：////Ifeverythingsucceeded,thenenablepagecachingasindicated//bythecurrentapplicationconfiguration.//if(DuwamishConfiguration.EnablePageCache){//EnablePageCaching...Response.Cache.SetExpires(DateTime.Now.AddSeconds(DuwamishConfiguration.PageCacheExpiresInSeconds));Response.Cache.SetCacheability(HttpCacheability.Public);在Page_Load事件中最后判断是否允许页面缓存。3,验证数据合法性类ーSystemFrameworkXApplicationAssert.csSystemFrameworkXApplicationAssert.csClass用来进行错误检测,并调用SystemFrameworkXApplicationLog.csClass记求错误1—I心、〇学习其中的部分代码片断:CodeSnippet1—CheckMethod[ConditionalAttribute("DEBUG")]publicstaticvoidCheck(boolcondition,StringerrorText,intlineNumber){if(!condition){StringdetaiiMessage=String.Empty;StringBuilderstrBuilder;GenerateStackTrace(lineNumber,outdetaiiMessage);strBuilder=newStringBuilder();strBuilder.Append("Assert:").Append("\r\n").Append(errorText).Append("\r\nH).Append(detailMessage);ApplicationLog.WriteWarning(strBuilder.ToStringO)3System.Diagnostics.Debug.Fail(errorText,detaiiMessage);))[C〇nditionalAttribute("DEBUG")]定义Check()方法为conditionalmethod»如果预处理符号(preprocessorsymbol)没有定义,compiler不仅忽略该方法,而且忽略对该方法的调用,和#ifDEBUG/#else/#endif有些类似。该方法用来判断条件condition是否为true,如果为false,则调用SystemFramework\ApplicationLog.WriteWarning()方法记录错误日志。CodeSnippet2—CheckConditionMethodpublicstaticvoidCheckCondition(boolcondition,StringerrorText,intlineNumber)//Testtheconditionif(!condition){//AssertandthrowiftheconditionisnotmetStringdetaiiMessage;GenerateStackTrace(lineNumber,outdetaiiMessage);Debug.Fail(errorText,detaiiMessage);thrownewApplicationException(errorText);))该方法一般用来在进行前置条件判断,如condition为false,则抛出exception〇4,log日志类ーSystemFrameworkXApplicationLog.csApplicationLog类实现Duwamish7.0中的记录和跟踪。Web.Config文件中的配置设置确定是输出到EventLog文件、跟踪日志文件还是两者。下面是Web.Config文件中的<ApplicationConfiguration>节,它指定EventLog设置:<ApplicationConfiguration><!—Eventlogsettings—><addkey="SystemFramework.EventLog.Enabled"value="True"/>oddkey="SystemFramework.EventLog.Machine"value="."/><addkey="SystemFramework.EventLog.SourceName"value="Duwamish7"/>oddkey="SystemFramework.EventLog.LogLever,value="1"/><!"UsethestandardTraceLevelvalues:0=Off=Error=Warning=Info=Verbose—>Web.Config文件的同一节还指定跟踪配置。Duwamish7.0跟踪日志的默认位置是:［安装VisualStudio.NET的驱动器号］:'ProgramFiles'MicrosoftVisualStudio.NET2003\EnterpriseSamples'Duwamish7.0CS'Web'DuwamishTrace.txt在实际的应用系统开发中,用来提供Log功能的类应该比这个ApplicationLog类要好,这样就不去分析了,如MicrosoftExceptionManagementApplicationBlock就不错。Web.config配置文件一使用Web.congfig文件存储application设置Duwamish7.0通过使用Forms身份验证来实现安全性。Forms身份验证将未经授权的用户重定向到Web窗体,该窗体提示用户输入其电子邮件地址和密码。(1)配置Forms身份验证Web.config文件中的设置配置Forms身份验证。对于Duwamish7.0,Web.Config文件按如下所述指定Forms身份验证的使用:<authenticationmode="Forms"><formsname=".ADUAUTH"loginllrl="secure\logon.aspx"protection="AII"></forms></authentication><authorization><allowusers="*"/></authorization>authentication元素只能在计算机、站点或应用程序级别声明。如果试图在配置文件中的子目录或页级别上进行声明,则将产生分析器错误信息。如上所示,Web.Config将.ADUAUTH指定为身份验证Cookie的名称。当用户请求受限资源时,公共语言运行库将未经授权的用户重定向到在上面的Web.Config设置中指定的Login.aspxoprotection="AII"设置指定应用程序使用数据验证和加密来保护Cookieo若要进ー步限制资源,Duwamish7.0会将安全资源放置到名为secure的子文件夹中并使用额外的Web.Config文件（在secure文件夹）,在该文件中指定只有经过身份验证的用户オ可访问该子文件夹的内容。<authorization><denyusers="?"/><allowusers="*"/></authorization><denyusers="?"/>标记指定拒绝对所有匿名用户的访问。vallowusers="*"/>标签允许访问所有已验证身份的用户。经过secureMogon.aspx认证通过的请求,重新定向最初的URLo〃将已验证身份的用户重定向回最初请求的URLoFormsAuthentication.RedirectFromLoginPage("*false);(2)用户定义的配置节<configSections><sectionname="ApplicationConfigurationHtype="Duwamish7.SystemFramework.ApplicationConfiguration,Duwamish7.SystemFramework"/><sectionname="DuwamishConfiguration"type="Duwamish7.Common.DuwamishConfiguration,Duwamish7.Common"/><sectionname="SourceViewer"type="System.Configuration.NameValueSectionHandler,System,Version=1.0.5000.0,Culture=neutral,PublicKeyToken=b77a5c561934e089"/></configSections>section元素包含配置节声明,name指定配置节的名称,type指定从配置文件中读取节的配置节处理程序类的名称。配置节处理程序(即实现IConfigurationSectionHandler接口的类)读取设置。上面定义了3个配置节处理程序:Duwamish7.SystemFramework.ApplicationConfigurationDuwamish7.Common.DuwamishConfigurationSystem.Configuration.NameValueSectionHandler前面两个配置节处理程序是由application提供的,后面的System.Configuration.NameValueSectionHandler是.NetFramework提供的,该类也实现了IconfigurationSectionHandler接口,用来提供配置节中的名称/值对配置信息。webXPageBase.es最后谈谈web'PageBase.cs基类吧,所有Duwamish7.0中的所有web页都继承名为PageBase的基类,该类实现Duwamish7.0应用程序的ASP.Net页中使用的常见属性和方法,这种设计方法值得推荐。CodeSnippet分析:///<summary>///Handleserrorsthatmaybeencounteredwhendisplayingthispage.//////<paramname="e">AnEventArgsthatcontainstheeventdata.</param>///</summary>protectedoverridevoidOnError(EventArgse){ApplicationLog.WriteError(ApplicationLog.FormatException(Server.GetLastError(),UNHANDLED_EXCEPTION));base.OnError(e);)重载OnError方法,使application遭遇到未处理错误的时候,自动调用ApplicationLog.WriteError。来记录错误日土另外,觉得Duwamish的password处理有些特别,是以byte形式存放在Database中,避免明文的方式,以提高安全性(将在《Duwamish密码分析篇》进行中分析)。Duwamish深入剖析ー结构篇摘要:本文深入详细的介绍了Duwamish网上电子书店例程的结构框架,并详细的分析了该结构的若干特点和设计模式。目录:引言Duwamish介绍结构分析设计思想代码示例总结作者引言:能够作为VisualStudio.Net附带的例子,Duwamish—定包含了微软.Net设计队伍希望向开发者传达的某些信息,而事实上,Duwamish也的确能够称作是ー个.Net开发者学习的经典示例,无论是从其设计架构,编程技巧或代码风格,都向我们展示了一个标准的.Net企业级应用程序所应该具有的特点。所以,通过研究Duwamish示例,高手能够领悟到.Net应用架构的设计思想,低手能够学习到.Net的编程技巧,实在是老少皆宜。:)不过,本文的目的更多的是针对中级.Net学习者,这类读者往往已经熟悉了C#或者是VB.NET的语法,会用ー些基本的类库,并已经会做一些比较小的程序。但是当他们开始着手开发ー个真正具有实用价值的企业级应用的时候,却有种无处下手的感觉。如果你正巧属于这类学习者,请跟着我深入到Duwamish的世界中去,相信你一定会得到收获。Duwamish介绍:Microsoft公司每次推出新技术,总是会相应的推出ー些公开源代码的应用范例来说明该项新技术的特点,而开发者也能通过研究该范例的代码来达到迅速掌握新技术并与以实施的目的。Microsoft通过对ー个虚拟的在网上销售图书的电子商务公司网上销售系统应用的创建,向用户展现了典型的网上购物实践中最为普遍的电子商务企业对客户(B2C)模式,它包括成员资格、帐户管理、购物车、搜索和结帐过程等基本功能。Duwamish经历了三个版本4.0,5.0和7.0版,每ー个版本的发布都印证了技术进步的过程,每ー个版本都代表了当时最先进的技术动向。这里将要研究和讨论的是Duwamish的最高版本7.0版,经历了COM/C〇M+技术以及Microso代DNA架构的Duwamish,在最新的版本中完全采用了.Net技术及架构,比以前显得更加先进和成熟。

如果您安装了VisualStudio.Net的话,您可以在您的VS.Net的EnterpriseSamples目录下找到并安装它,例如:C:\ProgramFilesXMicrosoftVisualStudio.NETXEnterpriseSamplesX,或者您还可以到http:〃/Duwamish7Vb/这个地址去看看它在Internet的ー个演示实例。其它有关Duwamish的详细介绍资料请参考VisualStudio.Net附带的MSDN帮助,地址是:ms-help://MS.VSCC/MS.MSDNVS.2052/dwamish7/html/vtoriDuwamishBooks70.htm,这里不再赘述。Duwamish结构分析:Duwamish7.0是ー个典型的N层架构,其结构分为四个逻辑层:Web层Web层为客户端提供对应用程序的访问。这ー层是作为Duwamish.sln解决方案文件中的Web项目实现的。Web层由ASP.NETWeb窗体和代码隐藏文件组成。Web窗体只是用HTML提供用户操作,而代码隐藏文件实现各种控件的事件处理。业务外观层业务外观层为Web层提供处理帐户、类别浏览和购书的界面。这ー层是作为Duwamish.sln解决方案文件中的BusinessFacade项目实现的。业务外观层用作隔离层,它将用户界面与各种业务功能的实现隔离开来。除了低级系统和支持功能之外,对数据库服务器的所有调用都是通过此程序集进行的。业务规则层业务规则层是作为Duwamish.sln解决方案文件中的BusinessRules项目实现的,它包含各种业务规则和逻辑的实现。业务规则完成如客户帐户和书籍订单的验证这样的任务。数据访问层数据访问层为业务规则层提供数据服务。这ー层是作为Duwamish.sln解决方案文件中的DataAccess项目实现的。比较令人困惑的是其中的业务外观层和业务规则层,很多人在学习N层结构开发的时候,听得最多的是三层结构,分别为:表示层,中间层和数据层。Duwamish的WEB层和数据访问层比较好理解,也就是传统意义上的表示层和数据层,那么业务外观层和业务规则层和我们熟悉的中间层有什么联系呢?设计思想:在Web应用程序中,有部分操作只是简单的从数据库根据条件提取数据,不需要经过任何处理,而直接将数据显示到网页上,比如查询某类别的图书列表。而另外一些操作,比如计算定单中图书的总价并根据顾客的级别计算回扣等等,这部分往往有许多不同的功能的类,操作起来也比较复杂。我们可以先想象一下,如果我们采用三层结构,这些商业逻辑一般是会放在中间层,那么对内部的这些大量种类繁多,使用方法也各异的不同的类的调用任务,就完全落到了表示层。这样势必会增加表示层的代码量,将表示层的任务复杂化,和表示层只负责接受用户的输入并返回结果的任务不太相称,并增加了层与层之间的耦合程度。为了解决这个问题,我们先来看看《设计模式》一文中对Facade模式的描述:意图:为子系统中的ー组接口提供ー个一致的界面,Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。适用性;当你要为ー个复杂子系统提供ー个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性,也更容易对子系统进行定制,但这也给那些不需要定制子系统的用户带来ー些使用上的困难。Facade可以提供ー个简单的缺省视图,这ー视图对大多数用户来说已经足够,而那些需要更多的可定制性的用户可以越过Facade层。客户程序与抽象类的实现部分之间存在着很大的依赖性。引入Facade将这个子系统与客户以及其他的子系统分离,可以提高子系统的独立性和可移植性。当你需要构建一个层次结构的子系统时,使用Facade模式定义子系统中每层的入口点。如果子系统之间是相互依赖的,你可以让它们仅通过Facade进行通讯,从而简化了它们之间的依赖关系。结构图:

上文提出的这个矛盾,正好和设计模式中Facade模式中所描述的需要解决的问题非常吻合,在《设计模式》中提出的解决的办法就是引入ー个Facade对象,让这个Façade来负责管理系统内部类的调用,并为表示层提供了一个单一而简单的接口。这个Façade对象,在我们的Duwamish的设计中,就是BusinessFacade（业务外观）层。以下是Duwamish的结构关系图:.NETg^m业务外理身浏宽器專浏覚鵲身浏览器结构关系忸客尸篇下列系统的公共入口点:.NETg^m业务外理身浏宽器專浏覚鵲身浏览器结构关系忸客尸篇下列系统的公共入口点:・•窖尸系统•订单系线•产品系故用于莒理以下方面的业务黑則:・订单-客戶散砧ジ问莒理所有低级数据访问的英・SQLServer系统框架・应用程序配置-异常处理-日志记录通用-用于书0、类别、客户和订単的自定义生成的数将集A・应用程序配置注我:衛头应解再为“.使用 "-例如:“数据访问”子系统正在使用“系统框架”子系我・我们从图中可以清楚的看到,浏览器首先调用的是表示层WEB,然后WEB将请求发送给业务外观层,业务外观层对请求进行初步的处理,判断是否需要调用业务规则层,还是直接调用数据访问层获取数据。最后由数据访问层访问数据库并按照来时的步骤返回结果到浏览器(对于图中涉及到其它的结构模块以后会分别予以详细介绍)。代码示例:以下是两种不同处理路径的代码示例:获取商品目录表示层调用业务外观层:productsystem=newProductSystem();categorySet=productsystem.GetCategories(categoryID);业务外观层直接调用数据层:publicCategoryDataGetCategories(intcategoryId)(if(dsCommand==nulI)(thrownewSystem_ObjectDisposedException(GetType()_Fu11Name);}returnFiIICategoryData(MGetCategoriesM5“©CategoryId"，categoryId);}添加定单表示层调用业务外观层:publicvoidAddOrder()AppIicationAssert.CheckCondition(cartOrderData!=null,"Orderrequiresdata",AppIicationAssert.LineNumber);AppIicationLog.WriteTrace("Duwamish7.Web.Cart.AddOrder:\r\nCustomerId:"+cartOrderData.Tables[OrderData.CUSTOMER_TABLE].Rows[0][0rderData.PKID_FIELD].ToString())；cartOrderData=(new0rderSystem()).AddOrder(cartOrderData);}业务外观层调用业务规则层:publicOrderDataAddOrder(0rderDataorder){AppIicationAssert.CheckCondition(order!=null,''Orderisrequired",AppIicationAssert.LineNumber);(newBusinessRules.Order()).InsertOrder(order);returnorder;}业务规则层调用数据层:publicboolInsertOrder(OrderDataorder){//此处省略复杂的处理逻辑if(isValid)(using(DataAccess.OrdersordersDataAccess=newDataAccess.0rders())return(ordersDataAccess.InsertOrderDetaiI(order))>0;}}elsereturnfalse;}总结:通过分析Duwamish7的结构设计,我们掌握了Façade模式,并学习到了如何通过Façade模式对应用结构进行改进,同时了解了Duwamish7的基本概念和处理流程,为以后深入分析和学习Duwamish7的的其它部分打下了一个基础。PetShop的系统架构设计《解剖PetShop》系列之ー前言:PetShop是一个范例,微软用它来展示.Net企业系统开发的能力。业界有许多.Net与J2EE之争,许多数据是从微软的PetShop和Sun的PetStore而来。这种争论不可避免带有浓厚的商业色彩,对于我们开发人员而言,没有必要过多关注。然而PetShop随着版本的不断更新,至现在基于.Net2.0的PetShop4.0为止,整个设计逐渐变得成熟而优雅,却又很多可以借鉴之处。PetShop是ー个小型的项目,系统架构与代码都比较简单,却也凸现了许多颇有价值的设计与开发理念。本系列试图对PetShop作一个全方位的解剖,依据的代码是PetShop4.0,可以从链接/library/default.asp7url=/library/en-us/dnbda/html/bdasamppet4.asp中获得。ー、PetShop的系统架构设计在软件体系架构设计中,分层式结构是最常见,也是最重要的ー种结构。微软推荐的分层式结构一般分为三层,从下至上分别为:数据访问层、业务逻辑层（又或成为领域层）、表示层,如图所示:

图ー:三层的分层式结构数据访问层:有时候也称为是持久层,其功能主要是负责数据库的访问。简单的说法就是实现对数据表的Select,Insert,Update,Delete的操作。如果要加入ORM的元素,那么就会包括对象和数据表之间的mapping,以及对象实体的持久化。在PetShop的数据访问层中,并没有使用〇RM,从而导致了代码量的增加,可以看作是整个设计实现中的一大败笔。业务逻辑层:是整个系统的核心,它与这个系统的业务（领域）有关。以PetShop为例,业务逻辑层的相关设计,均和网上宠物店特有的逻辑相关,例如查询宠物,下订单,添加宠物到购物车等等。如果涉及到数据库的访问,则调用数据访问层。表示层:是系统的UI部分,负责使用者与整个系统的交互。在这ー层中,理想的状态是不应包括系统的业务逻辑。表示层中的逻辑代码,仅与界面元素有关。在Petshop中,是利用ASP.Net来设计的,因此包含了许多Web控件和相关逻辑。分层式结构究竟其优势何在?MartinFowler在《PatternsofEnterpriseApplicationArchitecture》ー书中给出了答案:1、开发人员可以只关注整个结构中的其中某ー层;2、可以很容易的用新的实现来替换原有层次的实现;3、可以降低层与层之间的依赖;4、有利于标准化;5、利于各层逻辑的复用。概括来说,分层式设计可以达至如下目的:分散关注、松散耦合、逻辑复用、标准定义。ー个好的分层式结构,可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口,负责不同逻辑设计的开发人员就可以分散关注,齐头并进。例如UI人员只需考虑用户界面的体验与操作,领域的设计人员可以仅关注业务逻辑的设计,而数据库设计人员也不必为繁琐的用户交互而头疼了。每个开发人员的任务得到了确认,开发进度就可以迅速的提高。松散耦合的好处是显而易见的。如果一个系统没有分层,那么各自的逻辑都紧紧纠缠在ー起,彼此间相互依赖,谁都是不可替换的。一旦发生改变,则牵ー发而动全身,对项目的影响极为严重。降低层与层间的依赖性,既可以良好地保证未来的可扩展,在复用性上也是优势明显。每个功能模块ー旦定义好统一的接口,就可以被各个模块所调用,而不用为相同的功能进行重复地开发。进行好的分层式结构设计,标准也是必不可少的。只有在一定程度的标准化基础上,这个系统オ是可扩展的,可替换的。而层与层之间的通信也必然保证了接口的标准化。“金无足赤,人无完人”,分层式结构也不可避免具有一些缺陷:1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构,很多业务可以直接造访数据库,以此获取相应的数据,如今却必须通过中间层来完成。2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能,为保证其设计符合分层式结构,可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。前面提到,PetShop的表示层是用ASP.Net设计的,也就是说,它应是ー个BS系统。在.Net中,标准的BS分层式结构如下图所示:图二:.Net中标准的BS分层式结构随着PetShop版本的更新,其分层式结构也在不断的完善,例如PetShop2.0,就没有采用标准的三层式结构,如图三:PresentationTierBusinessLogicTierDAABSQLServer2000

Accounts,ProductsSQLServer2000

OrdersPresentationTierBusinessLogicTierDAABSQLServer2000

Accounts,ProductsSQLServer2000

Orders图三:PetShop2.0的体系架构从图中我们可以看到,并没有明显的数据访问层设计。这样的设计虽然提高了数据访问的性能,但也同时导致了业务逻辑层与数据访问的职责混乱。一旦要求支持的数据库发生变化,或者需要修改数据访问的逻辑,由于没有清晰的分层,会导致项目作大的修改。而随着硬件系统性能的提高,以及充分利用缓存、异步处理等机制,分层式结构所带来的性能影响几乎可以忽略不计。PetShop3.0纠正了此前层次不明的问题,将数据访问逻辑作为单独的ー层独立出来:PresentationTierASP.NETPresentationTierASP.NETWebFormsUserInterraceProcessingBusinessLogicTierBusinessComponentsEnterpriseServicesBusinessEnsesDataAccessLayerDALInterfaceDALFactoryBusinessLogicTierBusinessComponentsEnterpriseServicesBusinessEnsesDataAccessLayerDALInterfaceDALFactory图四:PetShop3.0的体系架构PetShop4.0基本上延续了3.0的结构,但在性能上作了一定的改进,引入了缓存和异步处理机制,同时又充分利用了ASP.Net2.0的新功能Membership,因止匕PetShop4.0的系统架构图如下所示:BusinessL09C

U)tfDMaAccess

UytrPresentationCt&ieinttiUmpont^iCMtoty.P^duainventorynemi0foMcirtMeflbtnhip

齢他rOmhMtabenhip^oviderProfleDALinterteFtOory[oetde]ISO”(HerEmoc

Cooo*"ot)OABusinessCoopootntshveolwyandOfdvsDaoAccess

iMrWeIE]FOftde||SQLIIQAi[ID/^JSQLM/SQL2K5

€hde1H

UemMh9DtibMe

SO.MlSOUKS

Oodtflg

PiolieOObese

SCIHHSOUKS

OrxZ"

OlderDiuuse

SQLHHSOUKS

Orach*

mwrtoryOitMe

"S''JAsyncfronotAOrders图五:PetShop4.0的体系架构比较3.0和4.0的系统架构图,其核心的内容并没有发生变化。在数据访问层（DAL）中,仍然采用DALInterface抽象出数据访问逻辑,并以DALFactory作为数据访问层对象的工厂模块。对于DALInterface而言,分别有支持MS-SQL的SQLServerDAL和支持Oracle的OracleDAL具体实现。而Model模块则包含了数据实体对象。其详细的模块结构图如下所示:

图六:数据访问层的模块结构图可以看到,在数据访问层中,完全采用了“面向接口编程”思想。抽象出来的IDAL模块,脱离了与具体数据库的依赖,从而使得整个数据访问层利于数据库迁移。DALFactory模块专门管理DAL对象的创建,便于业务逻辑层访问。SQLServerDAL和OracleDAL模块均实现!DAL模块的接ロ,其中包含的逻辑就是对数据库的Select,Insert,Update和Delete操作。因为数据库类型的不同,对数据库的操作也有所不同,代码也会因此有所区别。此外,抽象出来的IDAL模块,除了解除了向下的依赖之外,对于其上的业务逻辑层,同样仅存在弱依赖关系,如下图所示:业务逻辑层对业务、（策略的抽象封装。IBLLStrategy——K 业务避風层・核心的业、个 ~~ 务代64都在本模块屮・BLL图七:业务逻辑层的模块结构图图七中BLL是业务逻辑层的核心模块,它包含了整个系统的核心业务。在业务逻辑层中,不能直接访问数据库,而必须通过数据访问层。注意图中对数据访问业务的调用,是通过接口模块IDAL来完成的。既然与具体的数据访问逻辑无关,则层与层之间的关系就是松散耦合的。如果此时需要修改数据访问层的具体实现,只要不涉及到IDAL的接口定义,那么业务逻辑层就不会受到任何影响。毕竟,具体实现的SQLServerDAL和〇racalDAL根本就与业务逻辑层没有半点关系。因为在Petshop4.0中引入了异步处理机制。插入订单的策略可以分为同步和异步,两者的插入策略明显不同,但对于调用者而言,插入订单的接口是完全一样的,所以PetShop4.0中设计了IBLLStrategy模块。虽然在IBLLStrategy模块中,仅仅是简单的10rderStategy,但同时也给出了一个范例和信息,那就是在业务逻辑的处理中,如果存在业务操作的多样化,或者是今后可能的变化,均应利用抽象的原理。或者使用接口,或者使用抽象类,从而脱离对具体业务的依赖。不过在PetShop中,由于业务逻辑相对简单,这种思想体现得不够明显。也正因为此,PetShop将核心的业务逻辑都放到了一个模块BLL中,并没有将具体的实现和抽象严格的按照模块分开。所以表示层和业务逻辑层之间的调用关系,其耦合度相对较高:图八:表示层的模块结构图在图五中,各个层次中还引入了辅助的模块,如数据访问层的Messaging模块,是为异步插入订单的功能提供,采用「MSMQ(MicrosoftMessagingQueue)技术。而表示层的CacheDependency则提供缓存功能。这些特殊的模块,我会在此后的文章中详细介绍。Microsoft.NETPetShop4架构与技术分析分类:.NET技术开发2006-04-1722:1510886人阅读评论(7)收藏举报1.项目概述与架构分析微软刚推出了基于ASP.NET2.0下的PetShop4,该版本有了ー个全新的用户界面。是研究ASP.NET2.0的好范例啊,大家都知道,一直以来,在.NET和Java之间争论不休,到底使用哪个平台开发的企业级应用性能最好、结构最优、生产カ最高。为了用事实说话,通过对项目各方面的性能评估进而在比较.NET和Java的高下。用户做比较的这个项目就是Petshop〇正因为Petshop肩负着上面所说的重任,各方面必须是最优的,架构设计应该是经过慎重考虑的。所以其ー经推出,便成为了开发者、架构师等人学习、研究的典范。

日前微软推出了基于.NETFramework2.0开发的Petshop4〇新的Petshop4实现了与Petshop3相同甚至更多的特性,由于采用了MasterPages,Membership,以及Profile,SqlCacheDependency,但是代码量却减少了四分之一。同时,在事务、数据缓存、安全方面使用了.NET2.0附带的特性,构建了一个灵活的最佳实践的应用程序。TH€.H€TP€TSHOPTH€.H€TP€TSHOPExploreourwideselectionofwhatcouldb9yourfuturepetOurCstegorieBIRDSBUGSBACKYARDENDANGEREDFISH他们利用了ProjectConversionWizard把项目从ASP.NET1.1移植至リ了ASP.NET2.0,然后做了以下改动:.用System.Transactions代替了原来的ServicedComponent提供的事务功能代码实现:PetShop.BLL.OrderSynchronous的publicvoidInsert(PetShop.Model.Orderinfoorder)〇.用强类型的范型集合代替了原来的弱类型集合publicIList<ProductInfo>publicGetProductsByCategory(stringcategory)//Returnnewifthestringisemptyif(string.IsNullOrEmpty(category))returnnewListくProductInfo〉()；//Runasearchagainstthedatastorereturndal.GetProductsByCategory(category);}.采用ASP.NET2.0Membership来做认证和授权.创建了针对Oracle10g的CustomASP.NET2.0MembershipProvider.利用ASP.NET2.0的CustomOracle和SQLServerProfileProviders做用户状态管理,包括购物车等.采用了MasterPages,取代了原来的用户控件,来实现统一的界面效果.使用了ASP.NET2.0Wizard控件实现check-out.使用了SqlCacheDependency来实现数据库层次的缓存更新(cacheinvalidation)功能.使用了消息队列来实现异时订单处理。

2.整体架构:ASPNET20ASPNETForms,UserControls.MasterPage.WizardCacheDependencyPresentation

LayeriCacheDependencyFAeni)er>hipRoviderRofileProviderCacheOependencyfactoryBusinessLogic

LayerDataAccess

LayerMembershipSecuhty.Useraccosts.Login

ControlsRofileShoppngCart.Wish

LstUsersProiieTableCacheDependencyBusinessComponentsClBusinessComponentsCategory.Product.Inventory.Items.Ordeo.CartSynchOrderOrderStratSqlMembershipRoviderSQL20M2.整体架构:ASPNET20ASPNETForms,UserControls.MasterPage.WizardCacheDependencyPresentation

LayeriCacheDependencyFAeni)er>hipRoviderRofileProviderCacheOependencyfactoryBusinessLogic

LayerDataAccess

LayerMembershipSecuhty.Useraccosts.Login

ControlsRofileShoppngCart.Wish

LstUsersProiieTableCacheDependencyBusinessComponentsClBusinessComponentsCategory.Product.Inventory.Items.Ordeo.CartSynchOrderOrderStratSqlMembershipRoviderSQL20M/SQLMS

Oracle10g

Membemh<)DatabaseSQLX”/SQL2K5Oode10g

ProiieDatabaseSQL2WI/SQL2K5Orach10g

OrderDatabaseSQL2MI/SOrachInventoryD数据库:（暂略）项目列表:从整体可以看出,PetShop4的项目体系已经很庞大,考虑的方面也较3.0更全面复杂。;解决方案’PetShop'（22个项目）J.SolutionItems田就BLL+.Jp]CacheDependencyFactory用_<D：\...\feb\\±).車DALFactoryf.5]DBUtility+.司IBLLStrategy上@!ICacheDependency:±序IDAL土，,摩!IMessaging+,項!ProfileDAL+.JpMembership+MessagingFactory.豆!Model+・yHSMQMessagingナ必OracleDAL+33OracleProfileDAL+孕OrderProcessor\±i@1Profile+33ProfileDALFactory比.車SQLProfileDAL+33SQLServerDAL+.JpTableC