不知道是何种原因，搞软件开发的家伙总是喜欢没有必要的复杂性，就是和业务目标不一致的复杂性。比方说J2EE的开发看上去明显要比.Net的开发要复杂，为什么哪？因为人们总是认为要使用J2EE就必须使用EJB,真的是这样的吗？看看我们的处理的业务问题中只有20%能用得上像EJB这样重量级的方案，说它是重量级是因为它不得不依赖于EJB容器来运行（如JBoss,Weblogic,etc.),而且实际当中未必能全部利用容器提供的所有服务，而用户们不得不为此忍受性能的负载以及多余的硬件和成本的负担，对于开发人员或设计人员来说不得不牺牲OO的设计原则，因为EJB不得不从EJBObject之类的基类继承还必须遵循该死的EJB编码规范，系统已经失去了OO带来的灵活性。EJB部署的时候和调用它们的时候不得不写很多的部署描述符以及服务定位代码，即使是很简单的应用，这些为部署和服务定位而写的代码是整个应用代码的几倍，这样已经非常不正常了，一个好的系统重心应该集中在应用代码之上。更加糟糕的是依赖于EJB容器的代码不容易测试，不好测试的代码应该说不是容易维护的代码，无疑增加维护的成本（金钱，时间，人力）。
那么为什么很多开发人员非常喜欢使用J2EE 中那些重量级容器，即使他们知道不必这样作！这有很多的原因，有文化上的，有官方（sun）的推崇，等等。开发人员认为只有将系统开发足够重量级才能“对得起”客户，很多人这样回答“因为这是Sun推荐的标准“....，但是我们为技术至上论而牺牲了客户的利益和自己的利益。J2EE不仅仅是EJB,EJB只是其中一个小的部分。
所以综上所述我们必须得到必要的复杂性，而且要在综合因素（性能，成本，开发难易，维护成本）上得到一个平衡，我们应该使用轻量级的容器（如Spring)，业务对象使用POJO的方式来开发，业务对象不依赖容器，能够使用OO,适于测试，照样能够使用轻量容器提供的分布式的能力，照样能使用J2EE的服务，让这样的方案来处理80%的业务应用，另外的20%只用EJB来处理。何乐而不为？我们可以减少不必要的复杂性而带来更好的体验。
所以我们为什么不能实事求是，“正统”的东西未必全是真理，应该审视技术带来的利益！而不是毫无主见的盲从。
