你的位置:首页 > ASP.net教程

[ASP.net教程][CAMCOCO][C#]我的系统架构 总图


之前写的感觉有点乱,把架构的设计图先放上来吧,对照着说。

CAMCOCO架构能够支持的模型:

1、B/S程序,比如CRM什么的,和访问普通网站没什么区别,都是从WEB服务器上进行操作;

2、APP的服务器端程序。APP可以是原生的,也可以是HTML5的。APP都通过WEB服务器获取REST数据进行访问,保护SOA的安全性;

3、WINFORM程序的服务器端;

 

从设计图上可以看出,老胡把客户端(使用场景)分为了三类:

1、不可信远程客户端:意思是可以被任何用户使用的,我们无法确保用户不会通过URL欺骗、COOKIE欺骗等等非法访问的情况,SOA服务的访问需要一个secrtKey,这个秘钥是不能被客户端掌握的,这种情况下,这类不可信客户端只能通过WEB服务来作为跳板访问SOA,而SOA的秘钥则保持在WEB服务里,不直接交给客户端。

2、可信任的远程客户端:在局部范围内使用的一些场景,用户身份和安全性是可以得到保证的,他们不会进行各种欺骗或尝试破解获得SOA秘钥。那么他们可以直接访问SOA服务进行操作。

3、可信任的本地客户端:有一些本地化的服务,比如我们引入了消息中间件后,需要做一些消息队列处理的服务时,就可以跨过SOA直接访问业务层了。

 

WEB服务和SOA服务的集群化

集群化是一个比较高大上的名词,其实老胡就是把各种服务给分解开来,从功能模块级就开始进行解耦。

例如一个CRM里,老胡将功能系统进行拆分:

WEB集群 

1、框架WEB: framework.camcoco.com

2、身份验证WEB服务:passport.camcoco.com

3、组织架构管理WEB服务:org.camcoco.com

4、客户管理WEB服务:customer.camcoco.com

5、订单管理WEB服务:order.camcoco.com

6、....

SOA集群

1、身份验证SOA服务:soa_passport.camcoco.com

2、组织架构管理SOA服务:soa_org.camcoco.com

3、客户管理SOA服务:soa_customer.camcoco.com

4、订单管理SOA服务:soa_order.camcoco.com

5、...

框架WEB负责加载一个CAMCOCO的Client Framework,里面包含了一堆老胡写的JS,比如AJAX调用、场景保持及还原、数据提交验证、CSS样式等等。

其他的WEB服务都是一些轻量级的服务了,比如客户管理里面,就只做和客户相关的功能,比如客户列表、查询、新增、维护等等。

每个WEB服务后面是一个对应的SOA服务,WEB服务负责接收客户端数据然后转交给SOA进行处理。

这样拆分之后,今后老胡要做一个新项目,里面也用到组织架构、身份验证、客户管理、生产管理,那我们直接就把之前的服务调用过来,然后新做一个生产管理就行了。(当然这是理想情况,客户管理模块多半还是要修改的)

如果卖出一套程序给某家用户后,用户说客户这里我需要进行一些修改,那我们能很方便地定位到客户这个模块中,无论是从业务层开始修改还是只修改界面层,都是很方便的。同时在更新的时候,不会影响到其他功能模块的正常使用。

 

至于业务层,老胡设计的实体中不包含操作方法,所有的操作都是放在聚合中进行,实体只负责数据合法性验证。SO,老胡认为实体是可以交给之上任意层使用的,这样在各层间传递参数时就可以直接传递实体对象,而不需要设计复杂的接口函数将实体的各个属性分别传递下去了。

业务层里针对不同的服务包含了N多的业务单元,如上面的例子,那么里面就至少会包含CAMCOCO.Business.Customer和CAMCOCO.Business.Order,至于每个业务单元如何去设计,就根据需要了,比如你要用到消息中间件减轻压力,比如要用到IOC实现业务灵活转换。

 

总之,CAMCOCO设计的初衷就是:

1、每个业务都是可拆分可组合的,不同的系统可以共用尽量多的业务模块;

2、在框架允许范围内,尽量少的编写代码,且代码是尽量规范的;

3、单独业务(核心业务除外)不会影响全局系统的运行,不同业务可以交由不同人员完成,每个业务的不同层级也可以交由不同人员完成。

 

GO ON...