分析工厂模式三层架构认识与分析.docVIP

分析工厂模式三层架构的认识和分析 我们所认识的三层架构，其实就是将整个业务应用划分为表示层、业务逻辑层、数据访问层 三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。 普通三层：数据访问层DAL：用于实现与数据库的交互和访问，从数据库获取数据或保存数据到数据库的部分。 业务逻辑层BLL：业务逻辑层承上启下，用于对上下交互的数据进行逻辑处理，实现业务目标。 表示层UI：主要实现和用户的交互，接收用户请求或返回用户请求的数据结果的展现，而具体的数据处理则交给业务逻辑层和数据访问层去处理。业务实体Model：用于封装实体类数据结构，一般用于映射数据库的数据表或视图，用以描述业务中客观存在的对象。Model分离出来是为了更好地解耦，为了更好地发挥分层的作用，更好地进行复用和扩展，增强灵活性。 通用类库Common：通用的辅助工具类欢迎访问 工模式 欢迎访问 简单工厂模式又称为静态工厂方法（Static Factory Method）模式，属于类的创建型模式，通常根据一个条件（参数）来返回不同的类的实例。 工厂角色（Creator）是简单工厂模式的核心，它负责实现创建所有具体产品类的实例。工厂类可以被外界直接调用，创建所需的产品对象。 抽象产品角色（Product）是所有具体产品角色的父类，它负责描述所有实例所共有的公共接口。 具体产品角色（Concrete Product）继承自抽象产品角色，一般为多个，是简单工厂模式的创建目标。工厂类返回的都是该角色的某一具体产品。 通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交换 完善的三层结构的要求是:修改表现层而不用修改逻辑层修改逻辑层而不用修改数据层否则你的应用是不是多层结构或者说是层结构的划分和组织上是不是有问题就很难说不同的应用有不同的理解，这是一个概念的问题 三层架构是将代码按其作用分成三部分每部分解决自己负责的流程 在设计UI的时候我们不需要关心其中的逻辑和数据问题只需要空出对应的位置用于放置数据 在设计和修改的时候要解决的只是HTML的结构代码看起来干净利落做起来也是干净利落 UI直接将程序逻辑的任务丢给BLLBLL就开始构建具体的实现细节BLL的创建依赖于业务 例如一个文章系统BLL_Aticle就表示它是用于对文章的处理的BLL_Aticle可以提供给UI一个文章列表的recordset显示在UI的预留位置当BLL_Aticle需要从数据库中获取数据的时候就将任务丢给DAL层 DAL层专门负责和数据库打交道它从BLL获取参数组织一个有效的SQL建立数据库连接执行SQL进行更新或获取将返回的数据交给BLL 每一部分的业务都集中于一个UI-BLL-DAL的链中上下清晰了然 至于是怎样的便于管理和扩展将在后面结合实例进行分析 复杂的生命形式必有复杂的生存法则若想在自己的项目中应用好三层架构需要多用点心体会其中的应用法则 三层结构适合群体开发，每人可以有不同的分工，协同工作使效率倍增。开发双层或单层应用时，每个开发人员都应对系统有较深的理解，能力要求很高，开发三层应用时，则可以结合多方面的人才，只需少数人对系统全面了解，从一定程度工降低了开发的难度。 三层架构属于瘦客户的模式，用户端只需一个较小的硬盘、较小的内存、较慢的CPU就可以获得不错的性能。相比之下，单层或胖客户对面器的要求太高。 三层架构的另一个优点在于可以更好的支持分布式计算环境。逻辑层的应用程序可以有多个机器上运行，充分利用网络的计算功能。分布式计算的潜力巨大，远比升级CPU有效。 三层架构的最大优点是它的安全性。用户端只能通过逻辑层来访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了。 - 1 -