这个小型项目有点曲折，始于2006年，当时由于没有总结经验，所以后来又做了N个类似的项目，鉴于此，记下总结。
系统软件架构概括
系统采用了B/S结构， 多层运行模式，同时适用于Intranet/Internet。浏览器为第一层，作为系统的应用界面；中间层为以WCF为载体的SOA;应用逻辑服务为第三层；数据链接为第四层，作为系统的数据存取服务。此架构无须安装客户端软件，便于软件的分发和维护升级，适应了众多应用客户端分散环境下的运行和维护需求。
系统包含如下各层：
Web 层 － Presentation
Web 层为客户端提供对应用程序的访问。Web 层由 ASP.NET Web 窗体和代码隐藏文件组成。Web 窗体只是用 HTML 提供用户操作，而代码隐藏文件实现各种控件的事件处理。
中间层为通过WCF做中间服务，使应用隔离开来，这样有利于扩展和维护，同事提高了整个应用程序的伸缩性。
业务外观层 － Business Facade
业务外观层为 Web 层提供处理书目检索、用户帐户管理、订单生成、购物车等功能的界面。业务外观层用作隔离层，它将用户界面与各种业务功能的实现隔离开来。除了低级系统和支持功能之外，对数据库服务器的所有调用都是通过此程序集进行的。
业务规则层 － Business Rules
业务规则层包含各种业务规则和逻辑的实现。业务规则完成如用户账户和用户安全性的核查这样的任务。
数据访问层 － Data Access
数据访问层为业务规则层提供数据服务。
共享函数项目 － Common
各个逻辑层之间的关系图如下所示：
由开始的逻辑图进化到现在的安全分布式逻辑图：
那么具体技术实现也将如下：
进一步确定整个网站的运行序列：
根据前面我们的分析，那么我们就可以进行如下的设计：
接口设计
a.内部接口
用户接口包含所有的操作界面，即目前市面主流的浏览器。
数据验证上，从客户端脚本和服务器端，进行用户输入数据的验证，防止无效数据造成的错误操作。
UI相应速度上,使用 AJAX 实现无刷新,提高UI相应速度和性能.
b.外部接口
原有方案是本系统与其他软件系统共用一个数据库系统，统一的数据库服务器作为与其他系统的外部接口，这样耦合性很大，同时造成数据和结构不可控，所以现在所有架构都建立在service上，系统之间都通过SOA的集中来交互。
运行设计
运行模块组合
UI: 功能模块使用时候(包括用户登录),都会首先通过UI层次Security模块的安全验证(验证是通过Components模块里面的自定义的用于页面功能以及功能点验证的控件触发), Security模块会通过服务层获取用户身份数据,用于页面验证.
功能模块的实际功能实现,如果需要数据库支持,那么依然会通过服务层进行数据操作.
Service:通过WCF做中间服务，使应用隔离开来，这样有利于扩展和维护，同事提高了整个应用程序的伸缩性。
Business Logic: 服务层内部之间的组合关系,主要体现再依赖和调用,由上往下调用,逐级依赖,最后Service底层边界Data Access模块将调用Framework中的Data模块,Data模块将调用MS.EntLib3中的Data,向数据服务器发送数据操作命令和数据.
Framework: 该层次提供许多基础的功能模块,分别提供给UI,Service层里面的模块直接或者间接的调用,同时也可以看到Framework层次内部各模块之间再运行时也有互相依赖调用的关系存在.该层次的部分模块会依赖和调用Ms.EntLib3中的模块,一般是按照两个层次里面的模块名称,产生关系的.
MS.EntLib3: 该层次的各个模块是整个系统框架中最底层的,只会在运行时被更高层次的模块依赖和调用,同时该层次内部各个模块之间也存在依赖和运行时调用关系.
版权声明：本文为博主http://www.zuiniusn.com 原创文章，未经博主允许不得转载。