大型商城购物管理系统

结合自己所做项目以及收集资料，汇总大型商城购物管理系统设计开发的心得和困难

表示层struts, spring mvc, jsf,tapestry...
控制层：spring
数据持久层：hibernate/ibatis/jdbc，归根到底都是jdbc

Java作web应用的核心技术就servlet/jsp/jdbc/这几个，有空研究一下JDK,Spring,Hibernate,Tomcat等开源框架的代码，里面体现了n多的设计模式，代码规范等，一定会给你带来技术上的升华
  
目前php商城占据了大部分市场，跟着是.net商城，java商城没有几个好的，
为什么有这个现象呢，其实java语言的优势是非常明显的，银行电信行业基本都是以java为主，这个是我本人工作经历所见。包括现在淘宝/京东都有向java方向靠拢的趋势，由于java语言本身的架构是比较合适做大型应用，我们有理由相信java商城会由更大的发展空间。我们要着手解决Java开发成本高的问题，因此好的框架和开发模式是少不了的。
  
   
 
    我心目中最好的框架组合是：
    表示层:spring mvc 3.1 + annotation
    控制层:spring 3.1
    持久层：hibernate 3.6 +jdbcTemplate
    后台列表控件：displaytag 1.2
    Ajax框架: DWR 3
    JS框架 ： Jquery
    缓存机制：spring 3.1 cache + ehcache/memcached
    静态化机制： Freemarker静态化/spring mvc伪静态化
    页面技术： EL + JSTL +JSP
    安全框架 spring security
    搜索引擎： Lucene
    中文分词：IKAnalyzer
    模板引擎： apache tiles 2.22
  
  

  
    部署视图所需：
    数据库： mysql
    Web 服务器： windows 下用apache, linux 下用ngnix
    应用服务器： Tomcat
  
    另外一些分布式的技术，例如EJB/web service/JMS等没有使用，如果改变部署方案时或者需要集成其他系统时可能会引入。
  
 
    下面就比较关注的框架做个简单的对比：
  
    1 spring mvc vs struts2
    我们本来是采用struts1.3来开发，struts那层用的非常的薄，只是用于接收页面参数和拿到数据库数据之后打印到request中让页面展现。按理应该直接升级为struts2才对，但是看了spring mvc 2.5的annotation版本之后就抛弃struts2了,spring mvc可以让我很容易从页面拿到数据，并且采用非常少的配置和具有很强的灵活性，看了struts2之后觉得都是大同小异的思路，那我何必再引入更多的jar..
    2. hibernate va jpa ibatis
    Jpa跟Hibernate很类似，个人感觉没有hibernate灵活，hibernate在快速开发上是很有优势的，加上cache可以部分弥补性能上的损耗，另外尽量不用他的那个配置做复杂的关联。
    另外可以用jdbcTemplate顶上用的比较多的地方以提高性能。
    3. DWR vs Jquery
    DWR在js和后台java代码之间是很好的桥梁，尤其是跟spring配合的很好，但是Jquery在页面的功能是少不了，还好两者不排斥对方，那就一起用了。
    4. spring 3.1 cache + ehcache/memcached
     spring 3.1 直接支持cache了，这次hibernate的二级缓存可以退休了。如果在单机选择ehcache,集群方式采用memcached。 memcached是远程调用，性能必然会有损耗。
    5. JSP vs freemarker velocity
    自从JSP有了JSTL之后， struts 的标签我已经不用了，加上EL之后我也没有找到用freemarker velocity的理由，除了静态化之外，貌似JSP也可以做静态化的，这个我研究不深，如果有反对意见可以提出来。
    6. apache tiles vs sitemesh
    由于是学struts出身，tiles熟悉阿，而且现在也支持模糊匹配了，看一些网上评论说性能不会有太大差别，sitemesh3也许会好些，用生不如用熟。不过均不能达到那种实时生效的模板效果，谁能说说java怎么做？
    7. 其余几个就没什么悬念了， 由于现在免费的jsp空间比较多的支持mysql和tomcat, 所以这2个是我们要优先支持的，虽然我们也支持oracle等。
  
    问题：
    1。模板技术缺少灵活性，目前Php的大型商城系统有很多的模板可以用，这个也不全都是官方自己开发的，这个是Java商城需要向php商城学习的地方。因为java是mvc方式建设的，有java,jsp, html等，java class需要重启服务器才能生效，而且很难像php一样，把所有东西写在一个目录拷贝到服务器上即可使用，目前我还是没有什么好的思路能达到这个效果的，考察了apache tiles/sitemesh/freemarker/velocity等，都没有想到办法。。。只能做到内置好模板让用户挑选。要达到大家都能做模板的程度，需要把代码和文档继续完善和开源。
    2。B2B2C模式需要大量的人力物力，目前还不成熟。需要有实力和经验的人加盟我们。
    3。java开发代价是高了些，通过对框架的整合和默认约定，已经把后台代码的使用方式给固定下来，前台页面是比较耗时。但如何降低总体开发难度并开创一个Java品牌商城是很有挑战和难度的。











刚开始我们也提到，学会怎么使用框架只是程序员的基本功，但是我们目标不应该满足于此。所以我也建议大家多看别人优秀的框架是如何实现的，请问有多少人熟悉JDK/spring等的代码，如果你熟悉了也不需要看别人写的书要怎么怎么配置了。而且那种用法比较优秀，比较容易实现也会心里有底。只会跟着设计编码，不会思考因果关系的人那是程序员。当然我本身也是个程序员。。

以前公司也有尝试自己写框架实现整个流程的，我不用spring mvc，我自己写一个表示层的实现也是可以的吧，无非就是servlet或者filterchain而已? 拿到请求就根据配置路由到不同的服务不同的方法去执行而已，反射，annotation，xml都可以实现，笨点hardcode也可以的。就我理解最后都是调用servlet 的dispatcher去干活的，貌似spring mvc就是这样。
spring也可以不要啊，所谓的IOC不就是把bean都自定义在一个hashmap里面，外加一些功能，每次取的时候给他需要的东西就好。所谓AOP也可以不用啊，就是在方法前后加上一些advice，加些逻辑，笨点，手写行吧。
hibernate和ibatis到最后都是sql而已，无非是想办法让你更容易写sql，hql最后不都是变成sql啊， 会写sql就会写代码了。

最后回到根本裸泳的时代， 那本质就是jsp/servlet/jdbc。 jsp/servlet又是对http协议的封装而已，jdbc就是对数据操作的封装而已，webservice又是xml+http的封装，再底层又是0101的二进制了....

虽然以上总结过于简单化，不过我认为这个就是J2EE的本质所在。学习Java的基础知识才皇道。最后我学艺不算很精，以上也许是个歪论。。。

但最后经过试验之后公司还是回归了spring框架，自己维护一套表示层或者业务层框架而又跟主业不太相关时，那个代价也太大了点，而且功能无法跟不断升级的开源框架比。





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的关系等。

要先把业务做起来，架构是迭代出来的，不是一天拍脑袋定下来的、taobao最初是从cgi，php做的

参考：http://my.oschina.net/zhangthe9/blog/40833