架构设计的非侵入性原则

最近常常看到JAVA社区热闹异常，各类框架齐齐上阵，各路神仙尽显神通。.NET社区也不甘寂寞，高手都冒出来了，于是移植自JAVA的框架，自己独创的框架，大而全的框架.....且不说技术上的优劣，也不比谁的效率，其实我们在项目中选择一个框架的时候很多时候都是在考虑这个框架的适用性，因为在做项目的时候因为各种各样的原因我们会受到各种各样的制约而不能够随心所欲的构建系统，而且就算我们能够作主的时候也会因为框架本身的限制而作罢，这点在改造和重构已有系统的时候常常会出现，所以在我们选择一个框架或者设计一个框架的时候，适用性就很值得我们关注了。

这里我觉得有一点需要纠正一下，很多时候有些朋友发布了自己的东西都喜欢用XX框架什么的，但是很多时候是有误区的，所谓框架（Framework）指的是我们所需要我们遵守一定规则在上面进行开发的平台，可能还需要提供一系列的SDK来帮助我们开发。比如.NET Framework，呵呵。WSS也算是一种Framework，因为我们也需要遵照他的规则在上面做二次开，再比如Eclipse或者Sharp develope，struts都算是Framework。而iBaties，Hibernate之类的都不算，这样子的算是组件（Component），还有一类工具可以通过数据库生成数据访问代码，页面等等的，这个应该怎么说呢，可能应该算是代码生成器......

不知不觉说了很多不算废话的废话，那么什么是架构的侵入性呢？所谓侵入性就是指的这个架构设计出来的部件对系统的影响范围，比如框架的侵入性就很高，因为在一个工程中引入一个框架，你的整个设计都必须围绕这个框架来进行，一旦使用了，框架的可替代性几乎为0，这样子就是搞侵入性。组件的侵入性就比较低,比如ibaties，他可以在任何java框架下使用，甚至可以和其他ORM组件共存，你仅仅需要引入，配置，然后就可以使用了，你也可以用其他的ORM替换他，所以......这个体验应该是很愉快的。
所以话说回来说到如果我们在设计一个通用架构的时候就应该注意到这个一个非常重要的地方，除非我们只是自己拿来用用，否则我们不应该假设我们的设计的用户已经具备怎么怎么样的环境或者是需要做什么特殊的设计才能够使用。
这里打个比方，假如说我们在设计一个通用权限管理什么什么的时候我们就要想好，这是一个组件，还是框架，还是一个现成系统（复用通过改改代码实现，其实个人觉得这种设计很低级，虽然有的这样子的东西功能确实丰富）。确定了目标之后我们才好开始下一步，比如确定是一个框架的话可能发挥要自由一些，因为不需要高度的内聚，不过可能因为框架要设计的方方面面太多了，所以老是觉得个人的力量不足以搞这种东西出来。如果是组件的话就需要高度的内聚来实现非侵入式，比如引入DLL的时候还需要让所有页面继承自某个基类页就不算是一个good idear。
虽然话说得好听，不过我在自己做设计的时候还是常常因为功力不够造成一些侵入的现象，但是高内聚低耦合都是我们不断追求的目标，所以所有做设计的同学们一起努力吧
PS：这里卖弄了下词藻，呵呵，侵入就是在两个系统发生耦合的时候造成的...........
估计发首页会被人骂，我就想看看那些人会骂而已