框架设计的粒度

    框架设计的粒度到底应该划分的多细是一个需要考虑的问题，当然根据不同的项目所需要划分的粒度也不相同。这边文章只是为了记录此时此刻的思想，希望各位csdn上的牛人看过之后不要群起而攻之。

    先拿一个常见的OA中的权限管理举例，常规的设计方式无非就是权限、角色、人这三层，关系如下：

 

那么这样的权限设计是可以基本满足一个OA的需要的，那么只需要做一个Filter去进行权限的控制就OK了。如果考虑到软件的扩展性貌似也足够用了。但是考虑一下显示情况，如果上线之后权限需要增加意味着什么呢？首先添加权限系统是可以满足的，但是页面是否添加？或者是页面中需要添加新的功能？最后需要改变Filter中的代码呢？那么我们在设计的时候为什么不能再把粒度划分的细一些呢。其实并不是很难想到

    我们只需要将可控制的部分再细化一些。上面的数据结构只划分到了权限，但是权限意味着什么呢？意味着我们可以进行怎样的控制。但是往往我们就不再去想怎么控制了。那么怎么控制呢？其实无非就是我要执行怎样的代码。那么我们现在把代码一层以及所控制的资源也细分出来，就形成了下面的结构：

   

 通过着些许的改变就使得之前的权限管理编程了一个由开发者的意愿去自由的控制的一个数据结构了。我们可以由资源来决定权限的设置，也可以由于权限的需求来增加资源。注意资源和操作是没有物理关系的，但是去可以通过实际情况去编写他们的关系（配置文件），至于具体的实现可以通过反射机制或者beanShell来实现，这里不做具体阐述，我只是想说明一种设计理念。

    其实就像ITIL一样，划分的越细致，成本就越高。但是同时我们却可以提高项目可控性。这里的可控性范围很广，包括：项目的扩展性、维护性和资源的复用。

    其实配置文件也是一种资源同样可以记录在“资源”表中，通过一个成型的系统再生成并控制其它二级或者三级的产品，形成一个高度合理整合资源的平台。

   纯属个人见解，仁者见仁智者见智，望大家用批判的态度来看待这边文章，希望大家多提宝贵意见。