大型Java多用户商城系统设计开发的心得和困难

枉我这么积极回帖，不选个精华也要个良好贴阿,你要叫管理员赔偿我的损失.

不用MAVEN怎么了呢？我们是用Ant来编译的，外加eclipse的export.现在才project都不到10个，用MAVEN好像杀鸡用牛刀一样，主要是感觉MAVEN太重了，我主要几个lib而已，却给我下了1G大小的东西回来。

APPFUSE的MAVEN离线LIB包也才８０多Ｍ，不过APPFUSE也是从ANT转到MAVEN。

我觉得hibernate的限制并不在于千万级数据量(我们以前做过，再大我就不敢说了)。
一种情况可能是业务过于复杂，比如我们做的一个电力调度的系统，那种情况绝对不适合用hibernate。
另一种情况可能做的分布式存储时，需要做物理上分库分表等等。这样的话，hibernate就比较憋脚了

几百万上千万就把hibernate用跨了，说明你根本就是在乱用。

我这里数据量没这么大，没有发言权，你说说你是怎么用的啊

我意思不是说MAVEN不好，还有一个原因我没有想到如何在MAVEN中调用混淆器。用Ant就好办些，理论上MAVEN是可以调用Ant，只是Ant已经满足了我的需求，就不想多搞了。

说说我们的选择吧，前面提到我们已经放弃了Struts，转投到Spring MVC，但是Hibernate还是保留了。
原因有：
1. 我们是做平台的，客户要求多种多样，我们是需要支持多个数据库的，Hibernate可以比较容易屏蔽数据库的差异；
2. Hibernate采用面向对象的方式来写SQL，也就是HQL和Criteria,在数据库和Dao之间多了一层，数据库的改动可以通过映射关系屏蔽部分影响。
3. 因为我们是要不断的增加功能，偶然要做做系统重构，快速快发尤其重要，Hibernate的代码量和改动量都要比其他框架来的少，起码经过我们的封装已经使得用起来是很简单了。
4. 对于性能有影响的地方和很难用Hibernate表达的地方我们会采用JdbcTemplate，或者采用View封装一次再map到Hibernate，采用Hibernate也不排斥其他持久层框架的存在。
5. 尽量少用One to many, Many to one等功能，可能这里不太OO，但是代码明了,不容易出问题。
6. 我们暂时还没有遇到几千万的数据量那么大的客户，要做到那么大数据量的时候也可以从数据库，系统，网络各个方面来优化。系统推到重来也不是什么问题。
7.Hibernate的一级缓存对于长Transaction的业务复杂的代码反而有好处，见上面的某些分析。
8. 采用缓存和静态页面可以消除部分性能影响，或者采用数据库特有功能，不过取消Hibernate的二级缓存，采用Spring的缓存或者自己搞缓存。
9. 文档多，容易解决问题，也是JPA标准的重要参考。


Hibernate不好的地方：
1. 多占内存，因为他需要把domain对应的configuration都load到内存里面去，多用内存是正常的，但是出现OutofMemerey肯定不是Hibernate的问题了，一般应用内存还是够的。
2. 性能问题。Hibernate或者Ibatis也好，最终都是通过反射把ResultSet变为对应的Domain Object,跟了一下Hibernate的内部代码，好像是用Method.invoke来调用get 和set方法的，用了Cglib或者动态代理方式，这个方式肯定是要比直接调用get和set方法要慢的。在JDK不断优化的今天，这个差距应该会缩小。 但是Ibatais应该也是通过这个方式来做，没有看过不太肯定。Hibernate多了一个将HQL或者Domain Object转化为SQL的过程，这个过程也会消耗一些性能，例如字符串拼接，记录Domain Object的关系等。


经过以上分析，可能Hibernate会给我带来一定的性能损失，但是我可以通过其他办法来弥补，内存就更不是问题了。但是他确实带来了比较好的地方，因此我们会继续用Hibernate。

所以说Hibernate适合做企业级应用，对于那种内存和性能要求都很高或者本来就用Ibatis的情况，其实可以选择Ibatias或者JdbcTemplate的。就性能而言，
JdbcTemplate > Ibatis < Hibernate
除了缓存的作用外只说DB操作，纯JDBC是最快的，因为那样没有任何负担，但是代码搞得很难看，你会这么选择吗？

嗯 说的很中肯，消耗了内存，换取OO映射 也值

基本上我们也是用楼主你这样的架构，只不过我们自己做用户会话管理，把全文索引，文件服务，任务调度服务等都分开为一个独立的服务，可以单独部署。