你爸真厉害。
不过那个苦和现在的不一样吧？你现在的算梦想吗？
有段时间看了点WF, LZ的第一点似乎就是WF的初衷吧?
re: 先从应用层面考虑-emissary 0.1 chenpingjian 2008-03-22 21:24
联系我吧！我有跟你一样的想法，并且已经实现了一部分，13910722880，我正找志同道合的人呢。
你的应用服务器研究进展如何了，很关心这个东西，有机会共同研究。
MSN:bing.cai@sina.com
开发的怎么样了，我已经开发了一个您说的这种东西，基本已经实现了，你说的这些，有空我们联系一下。
不错的想法。
.net的确缺一些应用服务器。以前也觉得.net已经够用了，但是研究了ejb后发现，实际j2ee的开发效率并不低。当然像ebj2.0有些笨重，但jpa这样的方式出来了。或许让j2ee领域更好些。当然还有spring这样的框架。
re: 回顾3年的职业生涯 kiler 2007-06-18 14:31
厌倦了编码的人是做不了一个好的架构师的，也许pm更适合你吧。
其实我倾向于动态代理，不会使用“声明性编程”用原数据属性来干一些.Net Application Server所特有的活(先买个关子，下一文章再解释，因为很多东西不是技术因素决定的）。顺便，真的谢谢各位的支持。请尽可能地提些想法吧，然后我综合地来分析这些想法。
我看楼主的ECO就是用AOP的方式插入进来的。
AOP的方式有很多，比如反射，动态代理，字节码增强；
时机也有很多，运行时，编译时，等等。
TP,RP------> Biz object
TP,RP------> 【ECO（Your name）--->Biz object】
ok，你现在为了让Biz Object具有某些特殊功能，如日志，你不得不创建一个ECO（即便是自动生成的）。我不知道这比在该对象上加一个Attritue有什么好处。
---
开发人员开发的类不得不使用一些“声明性编程”的办法，类又与某些框架有关系了
---
我不知道还有什么比“声明性编程”所产生的污染更小的方法，自动创建一个保镖对象？
另外，在目前的解决方案，我更倾向于不直接使用某个分布式对象，而是对原有的业务对象做一层服务包装（Facade）。
比如BizObject A，BizObjext B是你个两个业务对象，他们没有任何的与分布式相关的逻辑，只体现领域模型。而我会创建一个Biz Service对象，他才是一个分布式对象，并且他会通过调用A,B实现某项需要暴露给客户的功能。
此时， TP，RP------>【Biz Service---->A,B】
而如果你需要在服务中使用日志之类的功能只要在BizService上做一些声明性编程，并不会影响到A,B的纯净性。
技术交流，言辞不当之处勿怪。