企业级应用开发架构的现状与趋势 - Part 1
目录
缘起
随着互联网近年来的迅猛发展，尤其是单页面Web应用（Single Page Web Application）以及Node.js的兴起，使得客户端和服务器端的界限越来越模糊了。
客户端从原来仅仅是展示页面和简单的校验逻辑转变为一个拥有完全状态的由JavaScript驱动的应用程序。
服务器端从原来的All-In-One（取数据，执行业务逻辑，渲染页面）到仅仅负责取数据和执行业务逻辑的无状态的Restful Service Provider。
未来的企业级应用的架构的方向以及技术实现可能会有非常大的改变，这个系列文章是我对于Java企业级应用现状的理解以及未来的展望。
把渲染页面的功能从服务器端剥离出来之后，带来的以下主要的优势
- 服务器端无需保存任何客户端的状态从而使得Cluster变得平凡，提升了服务器的处理容量
- 一个服务器端的实现能够支撑不同类型的客户端比如浏览器，IOS，Android
- 使得切换服务器端技术栈的成本降低，原先所有的页面都可以复用。比如我有legacy的Java系统有非常复杂的功能，我新的系统想用其它平台开发比如Node.js，我不会损失任何东西，原先的Java系统的接口都可以调用。如果按照以前的做法，整个页面都是用JSP或者JSF开发，那么基本上只有推倒重来了
- 开发页面的和开发服务器端的可以并行进行，互不干扰
- 使得在页面中写SQL和写业务逻辑变得不可能，一些老的Java系统经常有人图省事，把SQL直接写在JSP里面
开发人员和管理人员的困惑
在一次和项目内部开发人员的交流的过程中，我介绍了这个思路，不出所料的，得到了很多问题，比如
- JavaScript作为一个弱类型语言，能够支撑大的代码量吗？
- JavaScript没有Eclipse，没有自动完成，叫我怎么写代码？
- 听说Twitter已经从Client Side渲染转向Server Side渲染了，是不是说还是Server Side渲染性能好？
- 听说FaceBook已经在手机上放弃HTML5了，是不是出了什么状况？
- 公司已经在JSF上投入了这么多了精力，难道要放弃？
- 停止捣鼓新玩意，都是没有经过考验的东西，放在生产上能行吗？
我认为这些都是很好的问题，而且都不是一两句话能够说清楚的。有一点是确定的，人都是不太愿意改变的，尤其是自己已经非常熟悉的东西。我个人也是这样走过来的，再认识到这些之前，我用过JSF，Vaddin等等Server Driven的框架，当时由于我的背景以及当时项目的紧迫性，没有足够的能力来做完整的评估。后来慢慢的在项目发展中，碰到了种种困难，现在看来，虽然说当时的选择从现在来看是错误的，但是正是因为有失败才让我有动力去寻找正确的东西，正当我毫无头绪的时候，AngularJS进入了我的视线
AngularJS
在接触这个框架之前，我一直认为JavaScript只是个玩具语言，在加上网上各种对于这门语言的口诛笔伐，我一直对于它嗤之以鼻。但是在深入了解AngularJS之外，我彻底改变了想法。Module、Directive、Data Binding等等，直到现在，我仍然不能忘记当初的惊喜。
如果说AngularJS让我有了前面所说的思路，那么更为重要的是，它为我打开了更加精彩的Node世界的大门。没有了语言的障碍，Node很自然的成为了我今年最为重要学习主题之一。
Java企业应用的问题
如果说AngularJS完成了客户端问题，那么我们仍然需要一种方法来解决服务器开发效率和端性能问题。在这个方面，以Spring为主的主流框架几乎已经垄断了企业级应用的开发。如果你去问一个Java开发人员，也许5年前和现在相比没有本质的区别。如果说Java企业应用最大的优势是什么，很多架构师都会告诉你有非常成熟的框架和架构，而且Java语言就像普通话，外面到招人很好招，照此说来，Java解决方案就一点问题也没有了吗？
肯定不是！！！Java现有架构最大的问题就是，虽然Java是一个完全OO面向对象的语言，但是我们开发过程却只把它当作是过程式语言来用！！！你一定会问这是为什么呢？那请你看看你的代码，你的所有的POJO只是用来作为Hibernate Annotation的载体而已，而所有的业务逻辑都在所谓的Service类和Dao类中，那些类都是由一堆方法构成的，所有的这些其实都是与所谓的OO设计背道而驰的。
但是OO真的是解决问题的银弹吗，答案还是否定的。OO用来建模一个小范围的概念没有问题，但是如果想要用来描述现实世界中真正复杂的业务就有点力不从心了。想着过去多少次大家为模型应该是什么样子来争论不休，到头来谁也说服不了谁，我们都在寻找完美的模型，但是不幸的是，这样的模型要么不存在，要么就过于复杂，导致一般人无法理解。
另外举一个简单例子，每个稍微用过Spring都知道Dependency Injection，依赖反转，但是即使是很资深的开发人员仍然从来没有用过构造函数注入。
Java应用到最后都趋向一个大一统的野兽，大家回想一下，有多少次，因为一个无关紧要的Service配置问题，导致整个Web应用启动不了。有多少次你修改了一个函数甚至页面，结果要求完全重启JVM，要花个几分钟的时间重启Tomcat。
有多少次上面管理人员让你写单元测试，然后你发现，要写一个单元测试，必须加载整个Spring环境，跑一个单元测试要花几分钟时间等Spring帮你初始化好一大堆无关紧要的beans。到头来，你不得不放弃，因为写一个单元测试的成本太高了。
