流程命令需要规范

    对于基于AnyData的应用程序而言，流程命令绝对是一个好东西，但是当流程命令越来越多的时候，我发现这些对业务规则的实现起决定性作用的东西，开始泛滥，创建一个流程命令非常容易，只要通过.NET定一个DLL（EXE也可以）， 然后在其中写一个类Class，然后在类中添加一个Method，这个Method可以有Param，也可以没有Param，然后AnyData就可以通过通过如下的方式调用：
       DLLName;ClassName;MethodName;Param1 Param2
只要把这个字符串传递给AnyData，AnyData就可以调用这个库中对应的方法。
这太容易了，任何人都可以定义，所以就很容易泛滥。
或许，我们应该在这个DLL中规定一些签名函数，然后规定流程命令必须采用什么样的方式来组织。
还有，我们目前将DLL的代码保存在公司的TFS中，如果在客户的现场需要修改流程命令，怎么办？似乎可以将代码保存在客户的系统数据库中，然后可以通过脚本编辑器查看和编辑这些代码。客户服务工程师完全不需要回到公司，在现场即可解决用户需求变化的问题。
如果客户自己的工程师掌握了流程命令编辑和修改的技能（只要熟悉VB或C#即可），则无需我们的工程师到场，用户自己就可以根据自己的需求，对系统的行为进行调整。
    这样用户就可以购买AnyData平台，这个平台由我们的工程师和企业自己的技术人员和使用者联合定制，最后只需要企业内部人员自己即可定制，而开发人员只需要定期对Anydata进行升级即可。