spring的缺点(转)

来自:http://www.iteye.com/topic/17518?page=1
问题是我觉得rich domain object 和domain Dao双向依赖的关系我也很不喜欢。我觉得那么就像现在那么样，thin domain object，外加Dao层和Service层，单向依赖，分层很清楚，要么就向rails那样，就是一个model，管你dao还是service，全 部都在model里面。
赫赫，请问，没有domain model ,何来dao ，何来敲击键盘而来的代码？
dao依赖domain model是很理所当然的。 不过让domain model依赖于dao，确实很拗口，所以dao肯定需要一个接口，domain model依赖于dao的接口也是很合理的。这里的关键在于：
把DAO已经published的接口作为整个领域模型比较核心的一部分。 如果设计比较好的ORM 关联可能会把引入query 导致的双向依赖的危险减至最小，不会因为DAO接口实现的失败导致整个领域模型的错误，而把这种错误转变为领域模型关联关系的设计错误。

这里有个publish接口容易导致被误用的危险，DAO接口如果是领域模型提出的请求实现，那么这个设计就会很冒风险，因为如果一旦你的DAO接 口publish了，你就要冒着别的正在写domain model的开发人员会耦合于你的接口，一旦你的接口publish了，改动就非常困难了，而且如果一旦发现因为需求分析不够导致的DAO接口逻辑有问 题，那么这个将是非常痛苦的重构/修改过程。
所以关键在于让合理的关联代替复杂的查询。

说到接口，顺便说说对满天飞的interface的反感，我以前就是那样满天飞的，先在感觉飞的太高了。

接口其实就等同于代码隐藏，说句不好听的话就是代码私有化。 我发布一个接口，加上一些比较清晰的说明。 调用着一般都会只看接口说明感觉合适就直接IOC进来用了，久而久之就有可能被误用接口的危险。 如果没有接口，依赖代码就是文档的和相互可以修改的原则，那么大家都可以直入对方的正体，看一下对方代码的具体实现逻辑，有问题可以直接提出来探讨，这样 就减少了程序风险，而且也省去了来来回回反反复复修改interface 和实现的麻烦。
接口就如同是一个盖子，盖住了很多东西，然而在代码极度共享和互改的环境中，还是少用为妙。

我的观点是一个重要的接口都应该提供一个抽象类来实现基本的骨架!这样当你的接口改动时只影响你的抽象类。而对实现接口的继承抽象类的子类没有影响。 其实接口只是定义mixin(混合类型)的理想选择(java中接口才允许多继承)， 例如：一个教练本身也是球员。那么我们可以定义一个mixin接口，组合一些新的方法让实现这个mixin的抽象类不仅具有Train和Play的职责， 还有组合产生的特性。
一个缺点：不支持分布式部署。无法把一个bean给fail over或者re-deploy。
实际上，所有轻量级ioc容器真用起来都没什么用处，因为它们都无法应付分布式的需求。（jboss mc的作者跟我说的）

呵呵？谁有分布式的需求？

spring不是支持集群了吗？分布式就用不着了吧

有一个收费的T字头的方案能帮助spring实现分布式吧，没有免费的实现是挺麻烦的。

我们的做法是在5台tomcat服务器前面放一台四层交换机之类的硬件，这样，相同的ip来访问时会被指派到同一台tomcat,因此不需要http session共享，也能达到类似的分布式效果，还节约了session共享的消耗。

说到接口，顺便说说对满天飞的interface的反感，我以前就是那样满天飞的，先在感觉飞的太高了。

一直觉得interface就是C++里的.h 头文件，好不容易java里不需要.h,脱了苦海，现在大家又争先恐后再入火坑。

其实如果把interface用于动态proxy, cglib已经提供了解决方案，spring的OAOP,测试时的easyMock,都有cglib实现，性能比基于interface proxy的更高一点点。

如果是代码设计方面的，一定要看清楚实际情况再决定是否抽象interface。我觉得interface在代码设计方面最主要的应用其实是多重继承吧和firebody说的盖子功能吧。

所以springside里只有几个用到多重继承和webservice盖子的时候才用了interface. 比如dao, appfuse等sample为了演示多种dao方案才用interface阿，我们没事又不会换orm方案的，忙活这个接口没意义呀。