声明：
以下任何观点、理解，都有可能是错的，那仅代表作者在某一时刻结合自己的学习经历和思考得出的观点，很明显，这样的前提下很多都可能是错的。请各位在看到任何可疑观点时，都不要轻信，如果你们在喷我的时候能把理由一并说出来，那我就非常感激了。像什么“你懂的”，“当然是！不然还能是什么。”那样的话恐怕既说服不了我，也说服不了别人。
目前为止我对这几个框架认识：
我的理解不一定对，但是我还是在此首先明确一下我为什么选择的是Spring4+MVC+Hibernate4。
Spring就是用来提供一个IoC容器，它实现了一个Bean工厂，将我写的那些class的定义都搜集起来，并且在我需要的时候把它们给new了出来（至少是现在刚开始搭建这个平台时）。如果你曾经搭建过这样的平台，那么那些后缀中有Dao的，有Service的，最后在内存中工作的实例可能都是Spring框架new出来的。
2012年我初学Struts2，那时候MVC的Control层开源框架份额，已经是Struts2：SpringMVC=3:2，这才不过四年，现在SpringMVC的新项目层出不穷，而Struts2感觉一落千丈，只有原来公司产品包括Struts2的还在继续使用在新项目上。
说到这二者的区别，我只知道一点儿，而且也从未去证实过。据说Struts2的实现原理基于JSP的Filter，而SpringMVC则基于Servlet。对于JSP中Filter和Servlet的工作原理、实现机制我并不太清楚，所以不知道这二者在本质上将对Web MVC框架又怎样实质性的影响。
Hibernate，赫赫有名的持久层框架，其竞争对手无数，其本身缺点和优点似乎都很明显，在论坛、博客上都有着无穷无尽的讨论。Jeesite采用的是MyBatis，但是我还是最终选择了Hibernate，原因其实很简单，既不牵扯二级缓存，也不牵扯Hibernate的学习曲线。
我个人觉得在设计上，我期望Entity类本身自己就能说明其和数据库表、视图之间的关系（Hibernate现在可以全注解配置了），不需要额外的xml去描述。第二，由于我的初衷并不涉及数据库产品的切换，我个人更觉得像编程语言界百花绽放一样，技术应该处理它自己擅长做的事情，如果业务上数据的管理更类似二维表，数据的处理更类似数据集合中关系代数的演算，那么这部分业务就应该移到数据库端去实现。对象的特点，及其这么多年演变而来的设计模式，都说明了它擅长做什么，函数式编程语言、统计学的R语言都在各自领域蓬勃发展。
也许实际上有些事情很难做到，实际上我们在系统设计之初考虑的不是采用哪种技术实现设计，而是看团队中是懂Java的多还是懂.NET的多，以此决定是JavaWeb还是微软产品。这的确是无法回避的实际问题，而且面临这种情形我们可能会有相同选择。但如果作为技术讨论，那么我们就毫无必要去讨论它们，锤子适合砸钉子，无论你买得起还是买不起，本文的目的也是如此。所以为了Hibernate和它的全注解，它和表的一一对应这么简单的原因，我选择了Hibernate。
前端页面我使用EasyUI。虽然bootstrap看上去更互联网化一些，但是由于此次还是一个陈旧的信息管理系统平台，所以我个人觉得EasyUI看上去更好一点（这里的好是指：当我看到EasyUI时，它更符合我脑海中信息管理平台的样子，就像乔布斯看到施乐之星后，在车上反复说“就是它了”的心情一样）。
（未完，明天阐述一些xml的配置。但我也可能省略它们，因为它们在各类博客中被粘贴了无数遍）