(DSP处理器原理与应用)第9章应用程序架构.ppt

　　【本章提要】　　本章介绍了企业级应用多层设计的模式，阐述了应用分层的好处。并以校园在线超市用户注册模块为例，详细介绍了系统分层架构的实现过程。 　　【学习目标】　　· 理解从两层架构发展成多层架构。　　· 掌握将多层体系架构的理念融入到Web应用项目的设计和实施方法。 　　9.1.1 将应用分层的好处　　在大型公司里往往运行着大规模的软件系统，开发人员和分析师们专注于不同的应用层级。这确实是必须的，因为不可能让开发人员都理解某个层级所有的运行细节，若那样，则系统实在是太庞大了。 　　想象一下某个保险公司里的应用程序必须完成的所有功能。从最简化的流程来说，保险公司要能接收新的保险单，评估与保险单相关的风险，向投保者开出账单，打印保险单然后将它邮寄出去，处理保险单的索赔，更新保险单，如果过期(或者没有支付费用)则取消保险单，等等。这一巨大的流程显然不仅仅是一个桌面应用程序所能处理的。　　无论用户是不是想这么做，Web应用还是分层的好。如果用户是用SQL Server数据库存储数据的，那么数据库本身就已经是一个从Web服务器上分离出来的层了(即使物理上它们是在同一台计算机里)。 　　作为一个面向对象的平台，ASP.NET使得这种分层操作更加容易了。应用程序分层使得整个开发更加容易，因为分层将某些特定目的操作封装成一个个独立的模块，它们可以单独维护和修改，同时也分散了维护的工作量。　　例如，一个简单的在线零售程序采用了分层的思想，如图9-1所示。　　从图中可以看出物理硬件分层与应用程序分层的结合。实际上有三个分层运行于一个Web服务器上，第一层是Web站点的用户界面层(User Interface)，它由业务规则层支持， 业务规则层(Business Rules Layer)决定什么样的数据将被提供给用户界面层，业务规则层与数据访问层交互，而数据访问层则通过一个事务通道程序来获取所需要的数据，其他的客户服务和仓库系统也通过事务通道程序来获得所需的数据。 　　　　 图9-1 在线零售应用程序的分层 　　每一层都仅仅关注于自身的功能实现，如业务规则层不需要知道任何关于数据存储方面的信息，它只需要了解由数据访问层提供的接口即可。事实上，业务规则层完全不必关心使用什么样的数据库，或者是否存在一个数据库。它只需要了解有一个数据访问层能用于交互，以及它可以通过一个公共的接口来交互数据即可。　　尽管整个系统的完善需要集成测试，但是如果各层之间一致认同的接口没有发生改变，则我们可以在不干扰其他层的情况下改变任何一层的内部结构。 9.1.2 n级架构　　任何关于应用程序架构的讨论中，如果没有提到经典的n级架构，那么就是不完整的。“n”代表任何数字，适用于描述我们所创建的应用程序。层(layer)或级(tier)的数目，由应用程序块的需求和结构来决定。　　一般而言，甚至最基本的Web应用程序都能够被分离成三层：用户界面层(UI)、业务规则层(Business Rules Layer)以及数据层(Data Layer)。用户界面层就是用户能够见到的HTML和Web控件，业务规则层则承担着应用程序最重要的角色，而数据层则是数据库或者其他数据访问代码，这取决于应用程序的结构。 　　如果需要，可以将应用程序分得更细：用户可以拥有用户界面(.aspx页面)、作为用户界面“粘合剂”而被页面继承的类或局部类、业务规则层(业务规则类)、数据访问层(数据访问类)以及数据层本身(数据库)。　　假如由于某种原因，决定将SQL Server数据库替换为Oracle数据库，则如果没有将应用程序分层，而且把数据访问代码放在.aspx页面里，那么用户将不得不冒着把事情搞砸的风险，检查所有页面。这显然不是一种有效的代码管理方式。实际上，每个页面间操作数据的方式都不同。 　　如果把所有的数据访问代码都放在单个层里，如一个拥有操作数据方法的类，这样就可以在不破坏业务规则或者用户界面的情况下对代码进行修改。　　另一种很常见的情况是，假设在电子商务程序中，业务规则要求改变税款的计算方式，数据库没有变化，站点本身也不需要变化，仅仅是逻辑改变了，那就意味着只需要改变业务规则层中的类即可。再者，如果逻辑将创建在页面中或者是由某些数据库存储过程的计算所组成的，那么这项修改操作将变得十分困难。 　　在一个极端的例子里，税率可能经常改变，那么就不能将税率硬编码到代码中。一般的解决方式是将税率存储在数据库中，并创建用户易于操作的相关工具。 　　9.2.1 系统架构设计　　微软?.NET平台可以方便快速地开发和部署多层架构应用程序。在校园在线超市系统中，其架构在逻辑上划分成数据实体层(DML)、数据访问层(DAL)、业务逻辑层(BLL)和应用层(UI)