近几年涌现出各种技术，各种架构解决方案，导致开发新项目技术选型成为一个很重要的一步。当然每个框架的都有存在的目的和意义。
笔者不才就简单介绍一下系统的演变过程，如有不当之处请不吝赐教。
废话少说上图最关键（以下系统只针对J2EE）
很明显前端和后台以及数据库的连接都很单一，使用繁琐复杂。前端动态效果通过CSS样式和操作DOM树，后台业务逻辑代码臃肿，数据库连接需要写很多重复代码一不小心就会有实务问题。
有了问题就要解决，看下图：
前端变动很小，后台使用了MVC的模式，把控制层 业务层 视图层分离开来，代码的耦合性降低可维护性骤升。目前常用的用SSH框架，近两年使用较多的是SpringMVC.跟数据库交互的则产生的ORM 对象关系映射框架。通过ORM可以把查询转化成对象，使开发变得很easy.目前用的比较多的是hibernate, ibatis(Mybatis). hibernate对对象的操作表现的淋漓尽致，基本完全能满足开发需求，但其也有很大问题。首先是其很臃肿庞大，然后如果用的不熟练其性能问题是很严重的，最常见的问题就是1+N问题（懒加载），其优势就是可以快速开发，对于开发人员来说屏蔽了数据库（个人建议开发人员一定要了解清楚DB内存机制，优化机制）。对于mybatis来说没有hibernate的那些问题，其小而精，我感觉mybatis最大的优势就是自己扩展比较容易，尤其是其缓存。
总之hibernate适合对对象的操作，mybatis适合连表查询，具体使用哪个框架要根据各自系统的场景。
耦合性扩张性和对DB的操作都有了，问题又来了，我打开一个页面用了五六秒，这个事无法接受的。一大堆性能问题接踵而至，怎么办？看下图：
上图对前端和业务逻辑层跟DB交互层之间做了改造。随着后台技术的不断变革，前端也推出了新的解决方案，使DOM操作无缝化。
上个问题也说了速度很慢要五六秒才能打开，这时缓存就派上用场了。页面可以做缓存，后台也可以做缓存。第一次从DB里面读，第二次就可以从内存里面获取数据。当然并不是什么地方都可以做缓存的，对于经常访问并且数据很少会变化的才会使用缓存，否则反而适得其反。
如果一个系统变得越来越大该怎么办，最好的解决方案是拆分。把基础模块核心模块分成子系统服务化，对外提供接口。这样耦合性较低，系统扩张性较好，可以达到最大的重用。最后再多说几句，系统的架构要根据具体场景，系统能做多大要及时规划好，系统做大拆分成独立的服务是趋势（也就是传说中的分布式）。OK暂时说这么多啦！
