简介

在概念上,Glacier 是一个模式框架,核心很小但是扩展性很好,拥有良好的模式,可以让没有软件设计经验用户写出高内聚低耦合的代码,还能提高业务实现的效率。它也不会和其它框架冲突,可以在新 / 原有项目中使用,可以整体 / 局部使用,对于大一些的项目,可以在系统各处使用。

Architecure

控制反转/依赖注入

Glacier 架构由四部分组成,从核心开始支持 IoC / DI,这是现在最好的创建对象的方式,微软自家的框架比如 ASP.NET MVC / WebApi / SignalR 早就开始支持 IoC / DI。

Ioc/Di

Glacier 内置 IoC / DI 框架,也支持使用其它的 IoC / DI 框架,这样可以大大简少开发人员写很多创建对象之类的业务无关的代码,提高开发效率。

用了 IoC / DI,类型间的依赖关系只需要定义一次,类型的创建代码也只需要写一次,如果不用,类型被使用多少次就要写多少次。这是一个非常大的业务无关的工作,浪费了时间还增加了出错的可能。所以从不使用到使用 IoC / DI 是一个很大的提高。

组件基础设施

提供统一的组件基础设施,方便划分功能,定义依赖。

Module-Part Dependency

这里的 module 是一种隔离环境,module 和 module 之间不能依赖,但是 part 可以。part 用来在设计时解耦功能,而 module 在运行时隔离 part 的实例。

Module-Part Instance Mode

运行时每个 module 都会将其依赖的 part 树创建一份,使 module 和 module 不互相影响。

服务

然后向 part 内提供各种服务,以 Context 为核心,用户代码使用这些服务实现具体的业务。Context 上面的服务也可由用户自行扩展。

Context Services

提供更多的 service 也是 Glacier 的发展方向,Glacier 的收费功能一般都会以 service 的形式存在。比如集成的脚本服务,让使用者可以直接使用嵌入式脚本框架来完成复杂易变的工作。

命令

在此基础上,提供另一种功能隔离设施——命令模式,以满足不同层次的开发人员 / 团队使用。

Module-Part Relationship

一般,使用 Glacier 时,团队中水平较高的人定义好 module 和 part,也就是他们来划分大块功能。然后水平较低的人直接使用 Command,不用关心其它。

上下文

Glacier 会让任何地方都有 Context 可以使用,这样,开发人员可以方便的从 Context 上获取需要的服务,来实现业务逻辑。

Context Hierachy

这样的结构不但能带来写代码时的便利,也会给之后的修改、重构带来好处。因为开发人员会“自动”的把原本混在一起的逻辑拆分开。就算是初级的程序员,他其实清楚代码应该按功能拆分好,但是经验不足的时候只凭自己做不到,一旦有可以利用的框架,他就会很乐意做拆分,因为这样方便修改、维护自己的代码了。

其他

对于有些环境,module 的隔离性还不够,需要强化隔离

Isolation Mode

进一步支持 AppDomain 隔离和进程隔离,这就是一个 multi-tenant 体系的基础了。然后在隔离的基础上实现调用机制。

Call Mode

通过框架实现的进程内、进程间、设备间都远程接口的直接调用,这会大大简化一个大系统内各个子系统的交互操作。

对框架也能进行一些通用元素的扩展,比如软件功能控制,软件版本控制,以及命令过滤器,异常过滤器等等。

总之在框架层面尽量提供业务无关的功能。

上一篇