云4药品管理系统三.docx

三?架构分析与设计 架构设计是将需求内容转换成设计模型的雏形以及用户体验模型，其目的是建立整个系统初步的解决方案，为详细设计活动打下基础，这一阶段的具体活动如下：3.1 体系结构的选择 决定采取分布式的还是集中式的体系结构，将是一个影响系统性能、可缩放性、可靠性、易用性及此应用所能支持的客户端类型的重要决策问题。根据前期的需求知道，系统是为某单位设计的，考虑到后期的系统推广应用的可能性，采取分布式的体系结构将更适应于今后的变化所以采用分布式架构风格中有客户机/服务器（C/S）架构风格。框架选择：由于该系统仅在局域网内使用，用户数量有限，因此，决定采取局域网内的分布式的桌面信息管理系统方式实现此系统。根据前面的分析，我们采用. Net Framework 3.0框架实现该系统的，采用. Net Remoting实现客户端与服务器端之间的通信。 .Net Framework 3.0框架如下：基于三层结构的框架如图所示框架讲解： UI（界面层）：职责是数据的展现和采集，数据采集的结果通常以实体对象提交给业务逻辑层处理。 BL（业务逻辑层）：职责是按预定的业务逻辑处理UI层提交的请求。 （1）?业务功能子层负责基本业务功能的实现。 （2） 业务流子层负责将业务功能子层提供的多个基本业务功能组织成一个完整的业务流（事务只能在业务流子层开启）。RA（资源存取层）：职责是提供全面的资源访问功能支持，并向上层屏蔽资源的来源。(1) BEM（业务实体管理子层）：采用数据存取子层和服务获取子层来提供业务需要的基础数据/资源访问能力。(2) DA（数据存取子层）：负责从数据库中存取资源，并向BEM子层屏蔽所有的SQL语句以及数据库类型差异。 (3) SA（服务获取子层）：用于以SOA的方式从外部系统获取资源。(4) CA（配置文件存取子层）：用于从配置文件中获取配置信息或将配置信息保存倒配置文件。Entity（实体层）：跨越其他三层，在这些层之间传递数据。 规则（约束）：（1）系统各层次及层内部子层次之间都不得跨层调用。（2） Entity对象在各个层之间传递数据。（3）需要在UI层绑定到列表的数据采用基于关系的数据集传递，除此之外，应该使用Entity对象传递数据。（4）对于每一个数据库表（Table）都有一个DB?Entity?class与之对应，针对每一个Entity?class都会有一个BEM?Class与之对应。（5）有些跨数据库或跨表的操作（如复杂的联合查询）也需要由相应的BEM?Class来提供支持。 （6）对于相对简单的系统，可以考虑将业务功能子层和业务流子层合并为一个。（7）UI层和BL层禁止出现任何SQL语句。. Net Remoting框架图：. Net Remoting框架介绍： . Net Remoting提供了一种允许 对象通过应用程序域与另一个对象进行交互的框架。首先，客户端通过Remoting，访问通道以获得服务端对象，再通过代理解析为客户端对象。这就提供一种可能性，即以服务的方式来发布服务器对象。远程对象代码可以运行在服务器上（如服务器激活的对象和客户端激活的对象），然后客户端再通过Remoting连接服务器，获得该服务对象并通过序列化在客户端运行。这种框架提供了许多种服务，包括激活和生存期支持，以及负责与远程应用程序进行信息交互的通讯通道。数据存取架构分析： 该架构主要包括：数据源组件、SQL访问组件、SQL参数和结果集处理组件四大模块。其中，数据源组件主要负责数据库连接的管理；SQL访问组件负责数据库服务器的交互；结果处理组件模块负责处理从存储过程或查询操作类返回的结果数据；在整个架构中，凡是涉及到SQL语句参数的处理都交给类“SQL参数”。基于这种架构的数据存取过程，满足上述的预期目标。满足以上质量场景的数据存取层架构： 业务逻辑层架构设计： 业务逻辑层作为MIS系统的关键部分，对系统的灵活性实现起着决定性的作用。在本系统的业务逻辑层架构层中，采取了Fa?ade模式，下面简单介绍一下Fa?ade模式的好处：(1) 网络开销小，客户只需要和一个“门面Fa?ade”交互，只要一个网络调用就可以完成业务逻辑；(2) 客户端表示层和业务逻辑层得到解耦，完全分离；(3) 高效可靠的事务处理；(4) 良好的可重用性和可维护性。业务逻辑层的一种可用框架：Fa?ade模式在本系统中应用： 通过前期的需求分析，我们将业务用例模型中需要完成的业务流，分解成原子级的业务功能（图中的小圆圈），通过业务流（门面Facade）的整合，以实现业务用例模型中的预期用例功能。在系统开发期间，可以将业务流和业务功能的具体实现很好的解耦合，每个“门面Fa?ade”可以认为成对应了一个系统功能子系统，为系统的并行开发提供了可能。通过Fa?ade模式