后台框架--框架

摘自：http://www.iteye.com/topic/1134829#2411086框架层面：

 

SOA
在这一篇中会逐个介绍一下本身对这些XXX的理解，其实每个理念都不是莫名其妙产生的而是有产生背景的，这些时髦的名词不是用来炫耀的，而是真正要理解它们是干什么的，而且框架千万不能乱用理念也千万不能乱用，并非把全部的这些都用上你的系统才是一个牛逼的系统，必定要适合才是最好的，而且要保持简单可靠的原则。所谓SOA，字面上来讲是面向服务的架构。有的人不说SOA其实他已经SOA了，有的人大谈SOA但其实只是在用Web服务，SOA可大可小。你能够认为服务调用就是SOA了，也能够认为服务调用只是SOA中的很小一部分。我的以为SOA的理念是说，把业务逻辑从类库的封装提高到服务的封装，而且经过不一样的信道不一样的编码格式来提供服务，使异构系统之间也能重用服务，说白了就是让代码从本机重用提高到了跨机器的重用。从最简单的来讲，把组件封装成自制的服务，经过交换消息来使用服务提供的功能，那么就是SOA了，但这也仅仅是SOA的开始，好比你是否想过下面的问题怎么解决？

你的服务是否能够被外部的异构系统使用？
若是你的服务又须要调用另外的服务，怎么处理复杂的调用关系，怎么监控整个调用过程？
服务调用怎么归入事务的控制中？
服务愈来愈多，接口愈来愈多，怎么知道应该调用哪一个服务哪一个接口？
接口的版本升级了怎么办？
服务有太多人调用，怎么进行负载均衡，怎么限制调用人数？
怎么作安全，限制服务的匿名调用？
服务怎么进行测试？
服务调用失败后怎么办？
服务怎么进行升级和从新部署？
所以，SOA其实不只仅是调用服务，在监控和治理上有不少事情要作，SOA可大可小。无论怎么说，从理念上来讲，SOA确实是一种进步，复杂逻辑都封装成服务，一个复杂的系统可能调用不一样的服务就能够完成了，每个服务都是自治的，很好的下降了系统总体的复杂度。其实一个复杂的系统若是复杂度在10000的话，那么分红四层实现10*10*10*10就能够大大下降复杂度，每一层只要作好10复杂度就行了，由上层来调用下层。OSI若是不是七层模型，而是一层模型的话很难想象怎么去处理整个复杂的过程。
示例资源
 

RPC
字面上来讲就是远程过程调用，RPC（这里咱们说广义上的RPC）也能够是SOA实现的一种方式，SOA并不必定都经过Web服务实现。从实现原理上来讲RPC其实并非很复杂，无非就是客户端有一个代理，收集客户端要调用的远程方法以及参数，而后序列化成消息提交到远程，到了远程以后把消息反序列化，动态执行客户端所须要的方法（固然也包括建立对应的对象），而后把结果经过另一个消息返回给客户端，固然其中的细节太多了。从客户端和服务端交换数据依赖的信道来讲通常使用TCP或HTTP，也可能会是UDP。

ORM
对象关系映射解决面向对象系统和数据库阻抗不匹配的问题，你们都知道的ORM的定义。这里我想说的是ORM的出发点是好的，并且在某些应用中ORM确实能够改善代码可读性，增长编码效率，我的认为ORM是有使用状况的，不是全部的数据访问都适合使用ORM框架的，Java的SSH也有那么一点误导，Struts不是实现MVC的惟一方法，Spring不是实现IOC的惟一方法，Hibernate也不是实现数据访问的惟一方法，我以为ORM：

它适合领域复杂的，表多的，表之间关系多的，访问量相对较小的，企业应用。
它不适合业务相对简单，表之间关系很少，访问量超大的互联网应用。
对于ORM来讲要入门是简单的，可是要用好不是这么容易的：

若是没有正确使用极可能致使产生大量的SQL语句，而使用者还不知道。
若是没有正确使用极可能会拉取过多没必要要的数据，而使用者还不知道。
若是没有正确使用极可能会产生性能不高的SQL语句，而使用者还不知道。
所以，即使是使用ORM也要对ORM产生的SQL语句张一个心眼，而且咱们须要了解ORM中是如何作延迟加载、级联加载、主键缓存的，只有了解了这些机制才能真正用好ORM，若是对ORM不熟悉，若是在作互联网系统我以为仍是太平点吧，SQL语句精准高效。固然有的人要说了用SQL的话业务逻辑就可能不在代码中了，其实这个仍是看SQL语句怎么写的，若是把SQL只是当作数据库和程序的沟通桥梁的话这不是问题，若是在SQL里面作一些判断作一些计算那就是本身的事情了。示例资源

 

IOC
控制反转依赖注入不是嘴上说说的，它是一个很是实用的理念。有的人即便在使用了IOC以后尚未意识到为何要使用IOC，我总喜欢在面试的时候问为何要用容器来建立对象，本身手动new出来有什么很差？有的人回答是手动new出来的性能不高，容器建立的是惟一的对象，那我就会问本身写一个单例的对象也是同样的，为何要容器建立？其实这样的理解是有误的。我的认为管理对象的生命周期只是IOC容器的一个做用，IOC容器的意义在于：

管理了对象之间的关系。在OO中组合颇有用，若是对象之间有复杂关系的话，那么咱们就必须在new对象的时候来构建这种关系，这些关系其实都写死在代码中了。而且咱们经过代码会直接把实际的类型写死，下降了针对接口编程的意义。若是能在配置文件中根据本身的需求来配置这种关系，由容器动态建立对象和对象之间关系的话，那么咱们就把代码中依赖提取到了外部，由外部注入进去。在一个分层的应用程序中，咱们不只仅注入平行层级的对象，还能够注入下级对象，实现从上到下的自动注入，整个系统就很是灵活。
管理了对象的生命周期。有的时候出了单例或是new出来的对象，还会有根据线程、根据请求来的特殊声明周期的对象，若是手写代码来管理声明周期一来很麻烦，二来也不方便调整，经过容器来管理对象的声明周期简单高效，而且咱们很容易对容器进行扩展提供不一样的声明周期的字典便可扩展生命周期的类型。
 

AOP
面向切面编程对于职责分离和提升可测试性都很重要。通常来讲代码有两种方式织入，静态的和动态的。所谓静态的就是在编译以前直接改了要包装的类，而后把关注点的入口方法封装进去一块儿编译的编译时加强。所谓动态的就是在运行的时候动态修改代码动态编译的运行时加强。一旦有了AOP，那么咱们的事务、日志、权限、缓存之类和业务无关的代码就能够不出现和混在业务代码中了，根据须要进行配置就能够对任意的代码进行这些横切关注点的加强。一旦这些代码有修改，咱们也只须要修改配置，而不是在代码中的几千个几万个地方去查找修改。

 

MVC
MVC对于网站特别是互联网网站来讲是一种很是好的里面，MVC的优势体如今：

职责分离，再也不是全部的代码都混在一块儿了，V和C的分离尤为重要。
职责分离早就了能够进行单元测试，可测试性也是重要的一环，对C能够进行单元测试是很是重要的。
大多数MVC框架都提供了AOP的织入点，在实现职责分离的时候还能实现横切关注点的自动执行和可替换性。
在实现MVC的时候咱们不只仅是能把MVC框架用上去就行了，要尽量实现：

C中的诸如缓存、权限、日志之类的横切关注点务必提取出来经过AOP实现，不要和C的其它业务性逻辑混在一块儿。
C中的Action能够重用的尽可能重用，Action的结果能够重用的也尽可能重用。
能够考虑MVC和IOC相结合，把C用到一些服务或DAO动态注入进来。
对于V尽可能确保V中不要有后端代码，V可让前端开发直接编辑，由后端开发嵌入比较简单的Tag。若是VM明确的话，前端甚至能够直接写V。
 

TDD
测试驱动开发又是一个不小的概念。各类平台也有各类框架来实现Mock来实现单元测试。工具再好没有正确的编码理念也是没用的，要实现全部的代码都能经过单元测试来验证必要的几个因素包括：

程序没有很复杂的上下文环境，或者说上下文环境是能够被模拟的，不然怎么测试？
程序模块的职责是单一的清晰的，若是一个模块作了几十件事情，有几百个分支的话是很难测试，测试的粒度越是细越是容易测试。
针对如今大多数项目没法进行TDD，甚至没法进行单元测试的缘由是由于每每时间很赶，只能有时间实现最基本的业务逻辑，而单元测试其实编码的时间不会比实际的编码少的，甚至更多。我的认为能够根据项目的性质不一样来看，若是这个项目原本就是CRUD的，或者是一个临时的项目，单元测试TDD的意义不大。但若是这个项目是一个要被不少人使用的类库或者框架性质的项目，没有单元测试是没法想象的：

若是一个类库提供了100个功能，你不可能在修改了一个点以后就去手动测试一下这100个功能，必须经过自动化的手段进行。
类库须要确保在全部的边界状况都考虑到，手动测试或者黑盒测试是很难覆盖全部状况的。
若是你的类库没有提供单元测试，类库的使用者怎么在他们的执行环境来验证类库的可用性呢？所以还不只仅是给本身用，别人还要使用你的单元测试来确保类库在本身的运行环境下能够正常工做。示例资源
 

其它
在这里先想总结一下，我的以为这么多XXX中最须要有的就是MVC和IOC了，至于AOP有了固然更好，至于ORM和SOA则是看需求了，对于TDD么若是你在写一个类库或框架那是必须的，不然很难想象这套代码的稳定性会有多高。除了上面提到那那些XXX其实还有不少做为基础框架须要实现的东西，之前画过一个脑图参考：http://www.iteye.com/topic/1134828。做为框架我以为有一些要素是须要知足的：

尽可能保持框架对外的接口是很简单的，复杂的东西应该在框架内部处理掉，对框架的使用者透明。
框架的异常处理要完善，日志记录要完善，框架因为是对开发者透明的，所以最好在异常信息和日志信息中写明要调用者和框架的使用者怎么样去作才能解决这个问题而不是仅仅是说出了什么错。
一个完善的框架应该内建性能检测机制，或者提供http的接口可让外部了解到框架内部的运行情况。
框架要作好测试，确保在不一样的线程环境和不一样的配置状况下框架都能正常运行。
框架最好有性能测试，让使用者明确这个框架能提供的性能，以便正确判断是否能够知足本身的需求。