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

Hibernate我们觉得挺好的阿，用起来超级便捷。基于对象方式操作数据库对Java程序员很好理解，JPA也是这种思路的阿。 写代码和需求改动比写SQL速度快多了，有了这些自动化工具难道还要回去自己手动写SQL,一个一个写get and set?或者采用ibatis半自动方式？目前阶段快速开发才是王道。个人认为Hibernate，JPA这些全自动的工具才是以后的发展方向。不能因为它有难用的地方就抛弃它本身的优点，同时我们会采用JDBC，Cache等方式去取得一个平衡，拿首页来说，第一次从数据库中拿到数据后，所有数据即缓存下来或者生成静态页面去了，在数据有改动前可能有几十上百次访问已经不会再去访问数据库了。那个速度自然就提上去了。难点在于我们该什么时候去更新这些缓存或者静态页面，还有事务一至性，什么时候改用或者不该用事务，如何支持多个插件，多个模版之间的依赖和独立关系，讨论这些实际的设计问题，比单纯说那个工具好还是不好更有意义。也许我们到了访问量很大的情况的时候整个系统架构都变了，那个也许要一个逐渐改变的一个过程，一个好的系统架构不是一下子能搞出来啊，还是以实际数据作为依据来变化好。

采用Eclipse Jee加一个SVN插件，到google code去下载即可。不过目前分很多project，欢迎给意见。
另外这个楼已经盖的太高了，关于代码和技术应该另起帖子才对。要把这些技术和业务说清楚估计都可以写成一本书了。

连接不上呢

没有阿里的员工出来喷喷？

LZ似乎很用心在做这件事哦

因为，lz讨论的问题和海量数据的电子商务系统遇到的问题，不是一个问题。

好吧...没仔细看完，被打击了

认真看了一下文章跟回复
我确实觉得楼主只是在罗列一堆框架，好像跟商城电子商务没多大关系

一个企业级的小破系统同样适用这些个名词儿。。

不一样的东西 比如海量数据 缓存分布式之类的关键问题一点没说

我建议楼主要多花点时间在hibernate的预研上，有许多人说hibernate如何如何好用，操作数据库像操作对象一样方便，当他们遇到复杂的业务数据，不合理的数据库设计，高并发，异构数据库时，他们是否还会这么认为呢？

慎用hibernate，否则会搞死人的

+1
我觉得 对于简单操作来说hibernate 操作对象形势的存储的确 很方便。 但是对于复杂的业务逻辑等。海量数据，SQL的优化等。效率方面。真的会搞死人的。

通篇终于看完了，感觉楼主目标很伟大，现实有点残酷，加油了