Jalor3 中沿用的古老的七层Pattern架构，产生了大量吃闲饭的冗余代码，想必很多人都深有体会，恨之入骨。我们可不敢站在人民的对立面，于是我们决定精简代码层次，推出Jalor5框架，来解决大家的心头之恨。正如大家知道的，Jalor5 最终采用 展现层/服务层/数据访问层/数据库层的精简4层结构，不过这个四层架构的来历也并不简单。刚开始的时候，我们团队内部对新的架构存在一些分歧，部分团队成员坚持认为应该在展现层和服务层中间增加服务Facade层，理由是便于在这一层上进行权限控制和服务暴露，如果没有这一层，由于服务层之间的相互调用，权限将在一个网状结构中传递，众所周知，网状结构是难于控制的。
举个简单的例子：A服务，调用了B服务和C服务来进行一个完整的操作，在没有服务Facade层的情况下：
1. 如果ABC三个服务都控制了权限，难道我们要给用户授予ABC三个权限，用户才能使用A服务？这显然是不可接受的
2. 那我们换个方式：利用技术手段，只在A上控制权限，忽略BC的权限控制，有时候B操作是个关键操作，必须强制进行权限校验，也是不可接受的
3. 如果A是个批量保存的操作，他调用批量更新的操作B和批量新增的服务C来完成任务，这时A不控制权限，而交由B和C分开控制，对于没有新增权限的人，如果提交的数据中只有更新数据的，这个操作仍然可以成功。
4. 更复杂的情况，A服务是不控制权限的，B服务又调用了D服务，C服务又调用了E服务，或者交叉起来
显然问题的复杂性在一步一步上升。
我们来做个比喻，你去一个大的景点玩（A服务），买了张门票，到里面的大部分景点（B、C）是不需要再买新的门票的，但是有一些特殊景点可能需要。有的大景点是免费的，里面的小景点（B、C）要分开买票。更复杂的情况是，大景点（A）是免费的，里面有两个收费的中型景点（B、C），中型景点里面又有小景点（D、E），这些小景点只认对应的中型景点的门票（D只认B门票，E只认C门票）。
增加一个服务Facade层可以有效的解决这个权限的问题，权限仅在Facade层控制，也就不存在网状问题了。但是为了这少部分的权限场景，增加这一层吃闲饭的到底划不划算？我们可不敢再一次站在人民的对立面。
我们徘徊在大中小景点门前，思绪如那团网状的乱麻，我们真的要接受这个一刀切的超级联票吗?我们真的要放弃心底对极致简约的追求吗?
如果你看了标题，你就知道上面两个问题的答案是否定的。
有的时候我们走入了困境，总希望遇到可以指点迷津的大师。我时常梦见，大师拄着禅杖，道一声哦米拖佛，说施主你只需如此这般(此次省略411个字)便可。
其实，无论你指望，或者不指望，大师就在那里，也不曾走远，只是你看不见，也摸不着。EJB 的设计者中就有这样的大师。我们回想起 EJB 中的事务传播模型，发现 EJB 的事务就是在一个类似的网状结构中传播。
参考前辈的方案，我们将每个服务对权限的控制策略分成了几种：Mandatory（强制校验）、Required（前面校验了我就不校验，否则校验）、IgnoreAll（忽略后继所有的权限校验） 等几个级别，并引入了栈、桢来管理传播关系，权限拦截器根据服务的权限控制策略来进行必要的控制，这个问题也就迎刃而解了。
