这可能会被认为是“过度设计”，其实不然。我们总希望模块与模块之间的偶合性尽可能的小。好像只有几个JSP页面的应用没必要应用Struts，虽然它很优秀。这里依旧是抛砖引玉，我已经就此思路编写了部分代码，但是仍不成熟，尚存在一些疑难。最近较忙，春节期间我会把它们整理出来，希望能够为提高我们的效率做一些贡献。如果你有什么意见或建议，可以在JR的论坛里发帖子或者直接Email给我，kitta@163.com。在此先祝各位拜个早年，新年快乐，龙马精神！
－－ Kitta 2004.1
在哪里执行授权行为
授权行为要么发生在Model的上层，要么发生在Model的下层。
若要授权行为对Client“透明”，则发生在下层比较容易实现。
但是这违背了SRP[#1]：Model即要完成业务逻辑，又要完成授权行为。
因此应该在Model的上层完成授权行为。
ModelFactory
但是，若在上层完成授权行为就无法使之对Client完全“透明”。
不能再使用类似Model m = new Model()的方法获得Model的实例。
至少Client要通过一个上层机制来获得，这里将这种机制暂名为ModelFactory。
动态Proxy
保护逻辑的典型做法是Proxy模式：ModelProxy继承Model，并Override某些方法，
生成完成授权行为的代码，然后将通过授权的请求委托给Model处理，
拒绝未通过的请求并以某种方式通知Client。
但是，为每一个Model创建相应的ModelProxy实际上也是一种代码的重复。
因此我们希望用一种更简洁的方式来创建ModelProxy，即动态Proxy：
Client通过ModelFactory获得Model实例时，由ModelFactory动态生成ModelProxy[并返回。
用户获得的实际上是ModelProxy的实例。
注意，这里的意思不是在Coding时由工具根据Model和配置文件生成ModelProxy的代码，
而是在运行时根据Model和配置文件生成ModelProxy的实例。
- Model m = ModelFactory.getModel(Model.class,crdt/*Credential*/);
如何将未经授权的访问通知系统
ModelProxy收到未经授权的访问时可以抛出一个继承java.lang.RuntimeException的异常，
这样就不会影响继承层次。
[#1] 单一职责原则 参见RCM《Agile Software Development》第8章
|
|
