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

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

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

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

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

出于这个目的，我看了SQLServer的MetaDataService。很可惜，这个东西似乎与可以实现我的想法，可是资料却极少，MS自从2002后就没有更新过，看上去像被放弃了。

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

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

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

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

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

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

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

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

我在CSDN的VB.NET版，叫做bucher(无人永生)。
bucher_j@bigfoot.com

想法很好，但尚停留在表面，而且这些想法别人十几年前就想过了。另外，在VB里我认为只能有限度的实现你想要的东西。
　

我明白别人已经作过了，SAP的系统就是类似于这个样子的。
不过我觉得借助于现在的技术，我们可以在这个思想上扩展出新的东西来。毕竟这只是一个朦胧的想法。前人想过，但是很少有人付诸实施。
我觉得我的构思是完全可以变成现实的，所缺的是很多技术细节的探讨。
我很希望能够有一套适合中小企业的通用框架系统，这能够极大的节约开发人员的时间和精力。
我觉得开发语言并不是问题，关键在于架构的思想。有了架构的思想，任何支持OO的语言都能够用来开发这套架构

can't agree more:)
if you choose Java, congratulations, not too much things u need to elabarate:)
if C++, wow,cant image it:)--it doesnt mean impossible, but too hard.
I dont know vb

例如Delphi组件和JavaBeans组件以及EJB
定制可以发生在：
1.设计时，例如在IDE环境中
2.部署时，通过配置文件
3.运行时

和我的意思不一样吗? java有些事是作不了的,只能C++. 而有些事,C++会很麻
烦,一般作通用库或框架,C++好,java很多事情作不了.

在往前走，就会走到我所说的“面向资源”的开发方法。

只有当软件的所有基本要素和基本逻辑变成象水泥、沙子一样的“可视”的图形资源的时候，我们才能象建房子一样方便地“可视”地配置他们，而不需要“编程”。实际上，现在的程序就是一种“配置”，未来“配置”似的开发，实际上是另一种编程。比如XML，不过XML在可视化方面却是个倒退。

要充分发挥“可视性”的通俗化优势，“可视性”就必须从表面走向深入。从更深的层次开始“可视化”的迭代（自组织）。

和你的意思基本一样，
不过，你这一个贴字，我不太同意，应该说，在这种情况下，C++能做的，java基本都能做。但是，比如classloading用c++怎么做？除非你把compiler的内容搬上来。

我不知道这样的元数据怎么创建一个subclass 的对象的，能解释一下吗?thanks

no, I did not mean that.
我见过这样的系统，解释器和流程控制部分就是用解释语言作的，我一直想是一下用C++怎么做：）
其实只有一个问题我搞不明白。比如
原有的流程控制图中，依次A->B->C....->F, [A..F]就是元数据《节点/向量图>
，问题是，怎么能让控制流程的模块根据这一张图得出自动的代码？
更进一步，怎么让新加入的业务组件倍加栽进系统，而不需要更改代码，和编译。

这样的系统，erp中已经有了，我不是很了解，估计是用java相关语言写的。我希望知道用C++怎么实现。

--xml希望您能详细描述一下怎么用作OO的员数据驱动的?是要XML+OO database+java吗?,C++怎么做？
多谢

那位有关于这种有限“形式化语言“设计实现的东东？

XML+C++
其实用C++更适合作库,如果不是作库,用其他可能更好一些.楼主说的可能只局
限在管理软件领域,我想的范围可能更大一些,看来我误会了.

framework有水平（如j2ee)和垂直的区分，我说的就是垂直的。
我还是想知道XML和C++怎么样才能结合起来，用XML来实现C++属性的参数化控制是可以，只是怎么用XML实现对象的参数化，比如，在xml document定义了要用类型为class A的一个/或几个对象B处理这一message,问题是如何能像java一样自动生成一个这样的类型为B的对象。
XML实现属性不是什么新概念了，类似这样的form driving模型已经存在几十年了，只是用XML方便于在不同系统之间交互。
我想应该是有办法的。

 大胆预测：主流语言会由“过程式”转向“陈述式”语言...
　

---

很早以前（大概是1995年），曾经迷恋一种语言（Prolog）,她的承诺直到现在还记得很清楚：只要陈述所有事实和规则，算法自动产生。
我想当时Prolog不能成功，是因为没能建立起足够大的事实和规则库，另外，运算能力也不够。
不管结构化的语言、面向对象的语言，还是“面向方面”的语言，都是“过程式语言”。
java和.net的反射编程让code能够了解自己，这已经极大的增强了语言的灵活性和能力。
但只有当code在运行时能够像修改data一样修改自己，code才会有生命，才能在更多领域替代人类的脑力劳动。
最近sun提出的codat(代码和数据的混合体)是往这个方向靠近了一步。
现在，xml将有可能完成prolog未竟的事业。
至于运算能力，相信高速互联网和p2p运算能够改善这种状况。

dynamic loading, factory, proxy , ld, etc could partialy solve the problem.
using xml as a serializiation document sounds like a good ideal.

I still wonder how xparam could fulfil the class loading without force the whole classes derived from single base.
any idea?

呵呵,idea有一些,不过都不是太成熟,其实,这样的系统做出来会有多大的价值还需
要研究.

价值？呵呵，它的价值在于在大公司的rd部门很重要。
在此基础上可以实现特定领域的智能计算--business ondemand就是一个例子。
谈谈你的解决之道。xparam等我没有时间仔细分析，我们和其它公司的产品一般都要求这些对象有共同的base.

hehe,really, 200 years late?,nop,definitely not, the products is( at least is) in market.the business components are not perfect,but the foundamental architecture is good.

当然,陈述式语言几十年前就有了,但要想在一般性的应用领域取得统治性地位
,还有很长的路需要走,也许200年都不够,不光是技术上的原因,还有商业上,因
为这种方向与大多数开发商的利益是有矛盾的.

当应用领域被严格定义在一个很小局部时,有很多现成的东东可以参考. 技术
上也没什么太难理解的,需要的只是选择一个最适合具体历史的,现实的环境的
技术,采用单根结构也是一种不错的方式,尤其在java里.

全世界也就中国国情特殊，所以要单独看，未来的大本分软件公司，也就是别人产品的熟练使用者：），象uml/xml本身很不错，只是被某些公司无限夸张了。
xml没来就是用于交换和数据表达/存储用的，uml更是了不得，用java/j2ee, 。net的话，uml的case tools是不错，适用于开发生命，就是因为基础框架已经定型了，我还没有看到过C++上的n tiered分布计算的例子，可能试我比较愚昧：），只是觉得要从一个系统全局看的话,uml表达系统控制部分几乎作不到，只是对于分析oo部分作用明显。

hehe,I have the different aspect.
你喜欢从应用开发角度考虑，我喜欢看产品，java本身就是一个平台，所以，作其他平台的话，一般不考虑java.
这种应用模式的大小不是受限于构架，而是1.business component.2。业务系统的刻自动表达性。
比如，以前对于一个中间引入公共干预的业务流程，几乎不能定义。比如call center系统的人工处理逻辑，没有人知道该agent下一不会干什么。
目前，这一问题有所突破，但并没有最完美的解决。

和中国国情没关系,中国这点应用开发商的力量,还左右不了技术的发展潮流
.我们最好找一个mail list讨论,这个论坛不太适合作深入讨论.

是的,我们看问题角度不完全相同,其实这个问题描述的也不是很清晰.