• B/S、C/S混合场景下的层次架构方案


    软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式,层次系统风格即为其中一种,本文描述了一种适用于B/S、C/S混合场景的、基于层次系统风格的系统架构解决方案。

    一、    层次架构

    整个系统可划分为存储层、规约层、实现层、注入层、Web展示应用层、Web服务应用层、Client应用层共计七个层次,其中存储层一般对应关系数据库,其余六层是我们关注的重点。


    图1:层次架构图示

    将系统整体视作一个解决方案(Solution),观察上图可知,该解决方案主要包括下述九个开发项目(Project):

    1. Demo.Core:核心程序集,包含业务逻辑接口、数据访问接口和实体类;
    2. Demo.Managers:业务逻辑层的具体实现;
    3. Demo.Daos:数据访问层的具体实现,必要时可根据数据库类型进一步细分;
    4. Demo.IoC:依赖注入的实现,推荐采用Spring.NET,也可以引入工厂模式以反射的方式实现;
    5. Demo.Controllers:基于MVC思想设计与Web界面对应的控制器,为ajax交互提供支持,不推荐采用SOAP方式;
    6. Demo.WebUI:浏览器端界面,包含html、css、js和图片,遵循统一的界面规范;
    7. Demo.WebService:对外发布的web服务,供客户端(Client)或其它应用程序调用,推荐使用SOAP方式,可专门为.NET调用者封装WCF服务;
    8. Demo.ServiceProxy:web服务代理,它将实现业务逻辑接口封装Web Service的调用,是实现层的一个特例,供客户端(Client)或其它应用程序直接引用;
    9. Demo.ClientUI:PC客户端用户界面,同理可引入Demo.MobileUI用作手机客户端。

    单元测试并未纳入上述层次架构,在实际应用中应该再添加一个Demo.UnitTest开发项目,该项目将针对Demo.Core中定义的接口编写测试用例,这些测试用例将用作Demo.Managers、Demo.Daos项目具体接口实现类的验收标准。

    二、    编译依赖

    “层次架构”中涉及的九个开发项目之间存在一定的编译依赖关系,如下图所示,箭头标明了依赖性:

    图2:编译依赖图示

    Demo.Core不依赖其他项目;Demo.Managers 、Demo.Daos、Demo.IoC均依赖于Demo.Core;Demo.Controllers、Demo.WebService依赖于 Demo.Core和Demo.IoC;Demo.WebUI依赖于Demo.Controllers;Demo.ServiceProxy需要添加 Demo.WebService中web服务的引用,并非编译依赖,故以虚线表示;Demo.ClientUI依赖于Demo.Core和 Demo.IoC。

    此外,Demo.WebUI、Demo.WebService的正常运行需要Demo.Managers和Demo.Daos的支撑,Demo.ClientUI的正常运行需要Demo.ServiceProxy的支撑,这种支撑将以IoC的方式配置注入,因而不存在编译依赖关系。

    三、    应用发布

    Web展示应用层、Web服务应用层、Client应用层可统称应用层,因而在应用发布商,存在Web站点、Web服务站点、Client程序三个实例,且前两个可以二合为一。

    图3:应用发布图示

    四、    外部引用

    在应用系统开发过程中,对外部程序集的引用是一种典型现象,这里将其归纳为实现层辅助工具、业务逻辑路由、面向切面附加三类。

    1. 实现层辅助工具:在数据访问层(Demo.Daos)引入Spring.Data或Hibernate处理数据的存取。
    2. 业务逻辑路由:假设系统直接使用LDAP用户库,则可以添加一个实现了业务逻辑接口的适配器,将用户处理请求转交给LDAP服务器处理。
    3. 面向切面附加:面向切面即AOP,假设系统需要添加日志功能记录所有的业务逻辑操作,则可以添加一个业务逻辑接口实现类(AgentManager),该类持有另外一个接口实现类的引用(RealManager),AgentManager并未真正实现接口要求的方法,而是转交给RealManager处理,转交前后可加入日志记录代码。

    五、    架构演变

    某些情况下,我们可能需要在客户端本地缓存部分数据,此时Client程序将包含真正的业务逻辑和数据访问功能(上文Client涉及的业务请求是由服务代理转交Web Service处理的),Client应用层架构将演变为下图结构。

    图4:Client演变图示

    存储层一般采用文件级的数据库(例如SQLite),规约层、注入层、实现层的Demo.Managers 和Demo.Daos均为通用项目。注入层将同时控制注入远端处理逻辑(Demo.ServiceProxy)和本地处理逻辑,Demo.ClientUI根据需要自由选择,或者直接做一个业务逻辑适配器实现自动路由。

    六、    结束语

    本文旨在阐述一种松耦合的架构方案,指导思想是面向接口、生产者/消费者模式,规约层以接口为核心定义标准,实现层定位为生产者,应用层为消费者。在实际应用中,上文涉及的开发项目(Project)均可进行适度的合并或拆分。

  • 相关阅读:
    不要在该约炮的年纪谈佛系
    第三周文件处理和函数------上
    mysql的binlog和slow_log慢日志
    扩展中国剩余定理【模板】
    CF277B Set of Points——构造题
    ZOJ-3774 Power of Fibonacci——等比数列求和&&等价替换
    2019牛客暑期多校训练营(第九场)The power of Fibonacci——循环节&&CRT
    2019牛客暑期多校训练营(第九场)Quadratic equation——二次剩余(模奇素数)&&Cipolla算法
    2019牛客暑期多校训练营(第九场)All men are brothers——并查集&&组合数
    2019牛客暑期多校训练营(第九场)Knapsack Cryptosystem——哈希表&&二进制枚举
  • 原文地址:https://www.cnblogs.com/hxwzwiy/p/2412217.html
Copyright © 2020-2023  润新知