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

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

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

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

关于如海量数据 缓存分布式之类的关键问题，不知道能不能分享下，让大家学习下，不要只吐槽下就跑路了。

推销下guzz替代hibernate，可以看看，更适合商城类应用。

模板方面可以用guzz标签加velocity模板解决，通过上层自定义查询条件解析或自动分库分表（通过商家信息），解决不同商家之家的数据权限或性能问题，把数据的读取交给模板自定义查询语句即可。

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

1. java本来就号称高性能和安全，我们的目标当然不会是针对量不多的情况来考虑了。需要把各种情况考虑清楚，因为java是分层开发的，可以通过测试找出对应薄弱环节进行增强。
2. redeploy web app或者spring context个人觉得只是适合开发阶段或者趁晚上没人reload次数不多的情况，这种情况还不如重启服务器。不适合生产环境，reload过程无法提供连续访问，如果我们很多客户需要增加模板，频繁reload，那客户体验也太差了，生产环境是基本上不能停止的。淘宝也可以自己改模板，你见他有中断过服务吗？ 此法不可行也。

大型互联网公司后台用java的基本都选择的ibatis

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