一些关于系统架构实现的胡言乱语

类别:.NET开发 点击:0 评论:0 推荐:

前一阵子在写一个通用属性管理器,用于我们系统框架内的组件属性的管理。写着写着,忽然冒出了一些想法,在这里贴出来,希望大家能够来探讨。

首先准备只是写一个普通的属性管理器,通过关键字来获得某一个属性的值,就像COM+里面的SPM。这样我们可以通过一个集中的界面来维护整个框架内的组件属性。可以管理一些共享的属性,比如连接字符串、公司名称、WEB界面的缺省CSS文件名之类的。

<Step(“进化”)>设计的时候,觉得如果属性很多,管理起来不方便,后来决定使用命名空间来区分。于是变成了一个支持命名空间的属性管理器。后来发觉组件并不一定知道别的命名空间,这样访问一些共有的变量就很麻烦(不能在VS.NET的智能列表里面列出系统已注册的属性空间,需要程序员自己记住这些变量的命名空间),而这是我们开发的初衷。而且属性的安全也是一个问题,一个恶意的组件可以破坏掉整个系统。

<Step(“第二次进化”)>自然而然的,我想到了属性的权限,组件只能在自己的命名空间里面读写,只有一些拥有特殊权限的组件才能够读写整个命名空间。考虑了半天,准备使用windows的安全机制来实现。只有指定的用户才能够激活一些全局管理类实例(幸好VB.NET在这方面比较方便)。呵呵,是不是觉得很复杂了?我也这样想。对于全局属性,我决定使用继承来实现,也就是命名空间级别的继承,子空间自动只读继承父空间的所有属性,这样一些共有属性就可以很方便的管理和读取了。

<Step(“新的想法”)>写到这里,我忽然有了一个新的想法。既然属性可以这样自动化继承,类是不是也可以呢?其实现在这样的属性管理,只要类通过申明处于不同的属性空间,就可以得到不同的配置属性,来实现不同的特征。比如订单类,订单组件通过读取当前属性来构造自己。这样通过处于不同的属性空间层次,就可以得到不同的订单特征。我觉得这是一个很有意思的想法,我更希望类能够直接被继承,通过一些特殊的配置,让类具备新的行为。在命名空间内,通过装配和继承,可以实现很多新的特征和功能。在完美的世界里,可以不需要修改代码,就直接修改商务流程。在这个时候,属性的功能被扩大了,属性必须包括Overrideable,NotOverridable之类的特征。

<Step(“细节”)>出于这个目的,我看了SQLServerMetaDataService。很可惜,这个东西似乎与可以实现我的想法,可是资料却极少,MS自从2002后就没有更新过,看上去像被放弃了。

我的最终目的是实现这样一个系统:

1.  框架系统提供基本的服务,包括所有基本类型的实现(数据库访问,基本数据类型,通讯,一些通用商务对象…….的实现)

2.  开发人员可以通过一个GUI管理器来派生和扩展这些类,来得到符合自己要求的对象。当然,作为一个程序员,可以把自己写的类型插入到系统,来得到额外的功能。(这里面涉及到一个类型之间交互的问题,我还没有好的想法)

3.  业务顾问在Visio里面画出业务流程图,然后开发人员可以把最终商务类和这些流程联系起来(呵呵,受Biztalk影响)。

4.  系统引擎知道如何处理派生类,并且流程能够在商务流程变动的时候,重新编译。(这句话可能比较模糊,因为我发觉自己也很难把确切的想法表述出来)

5.  所有的类型,都可以实现安全管理。通过类型命名空间和安全命名空间的映射来实现权限继承和管理

<Step(“补充”)>当然,需要一个强大的缓存管理器来解决由此带来的性能冲击,这个缓存管理器我已经有了一些想法,不过已经超出了本文的范围,以后再讲吧。

<Step(“结束”)>对于这样的一个框架系统,我只是有一些朦胧的想法,还没有完全可行的方案。只是趁着自己还没有完全忘记,把它写下来,希望能够抛砖引玉,和大家一起探讨。

我在VB.NET版,叫做bucher(无人永生)

本文地址:http://com.8s8s.com/it/it45569.htm