现在正在一个J2EE项目上，对EJB进行了深入的研究，一直使用.Net的我终于发现EJB这种企业级组件的设计长处，当我需要设计一个业务组件时，只需要按照EJB规范写一个Bean(从SessionBean继承的普通Java类），然后在这个Bean中实现SessionBean接口中的回调方法和Home接口对应的ejbCreate方法，声明一个Home接口和Remote接口，最后使用部署工具将这个Bean部署到J2EE Application Server中去（Stub,EJBObject,部署描述符等等，全部由部署工具和容器产生，我只是开发了Bean而已），在使用时任何客户端都不允许直接访问Bean对象本身，而是通过Remote接口的容器所实现的EJBObject来间接访问Bean，这样EJBObject会自动拦截调用并让容器介入，容器会自动插入一些基础服务，如事务，安全上下文等等。感觉SUN这样的设计还是可以的。但是有些笨重，Bean必须从SeesionBean继承，这是一个侵入式的架构，个人感觉不是很好，因为我没有办法使用自己的继承体系，从应用层面来说，不是所有的应用都是分布式的，而EJB是一个分布式组件的解决方案，对于不是分布式的应用就显得性能等方面有些浪费。我也研究了Spring这样的解决方案，但是这个轻量级容器的.Net版本更像一个框架而不是一个实时的服务，虽然使用这样一个框架不会有太大问题，但是我总是希望有一个.Net Application Server即能提供企业级组件的基础服务，也能提供灵活的配置服务，开发人员只需要关注业务就成了，就像使用J2EE Application
Server一样有益处。所以现在正在逐步构思设计一个健壮的.Net应用服务器，使它能够处理大部分基础问题，使得.Net开发人员更有效率地构建他们的系统.
我会陆续地把这个设计的想法登陆上来。
