来自canonical blog的一些有益的思路

刚才去canonical的blog看了一眼。这么久之后，终于有多了几篇文章。
前面贴了一篇。
http://forum.iteye.com/viewtopic.php?p=127887#127887

这里还有一段思路也很有意义。

http://canonical.blogdriver.com/canonical/1162437.html
[quote=canonical blog]
但是我们需要记住软件设计的第一要义在于系统的分解, 而Browser和Server之间客观存在的http信道是天然存在的一种分界线. 任何强迫我们忘记B/S之间的界限的技术都是需要谨慎对待的. 例如控制后台对象的权限问题, 很多RPC方案限制了应用程序对于web接入层的直接接触, 而只能通过AOP(Aspect Oriented Programming)技术来动态织入权限控制代码. 在实际使用中, 这种方式往往因为service接口函数的多样化而造成配置上的繁琐. 而在我们的体系架构中, 系统边界划分在web访问层上(而不是java service层), 借助于web访问协议自身的一致性和透明性, 我们只需要如下实现
Object invokeWebEvent(){
return new ActionMethodInvocation(getWebObject(), getObjectEvent(), getInterceptors()).proceed();
}
就为所有WebObject加入interceptor堆栈, 完全不需要AOP的动态织入技术.
在witrix平台的设计中, 因为大量采用pull方案, 我们对于前后台交互方式采取的是完全开放的态度, 前后台的交互接口完全定义在web访问层上(即前台程序直接访问一个url获取数据), 尽量避免将系统架构的限制引入到应用程序设计中来. 确实, Browser和Server之间的原始交互方式是受限制的, 狭窄的, 但是从系统设计的角度上说, 这正是异构系统集成和进行系统核心控制的最好场所, 任何试图独占该连接信道并在层层封装之后提供更加丰富的访问语义的努力在我看来都是可疑的.
[/quote]


其中关键的一段，
"系统边界划分在web访问层上(而不是java service层), 借助于web访问协议自身的一致性和透明性,"

这个含义按照我理解，应该是说， xxx.jsp能够直接被 servlet web server认出来。根本不需要 xxx.do 再加上一大堆配置文件。

这就是前面那篇回答的帖子里面，我说的很有启发意义的 jsp controlet的思路。

-----------------

"任何试图独占该连接信道并在层层封装之后提供更加丰富的访问语义的努力在我看来都是可疑的"

这句话也相当经典。
很多框架正是如此，本来基本设施提供的好好的东西，非要包装的严严实实不让你看到，然后一点点在上面增加扩展，并把一些本来就属于你的东西，包装之后，再给你用，仿佛是自己新增加的特性。

这也是我的观点。
封装必须是具有很大附加价值的封装，而且封装的时候，千万不要挡住程序员其他的去路，原来的东西还要留给程序员。

-----------------

ps.
[quote]
Object invokeWebEvent(){
return new ActionMethodInvocation(getWebObject(), getObjectEvent(), getInterceptors()).proceed();
}
就为所有WebObject加入interceptor堆栈, 完全不需要AOP的动态织入技术.
[/quote]

严格来讲，这种比较是不公平的。
AOP本来的含义就是能够在任何点截获逻辑单位。
而这里只是一个入口处的特殊截获。

要说Web入口的特殊截获，还有Servlet Filter。
但我们只能说，Servlet Filter在这一点上提供了AOP interceptor plugin entry。只能截获一个类体系中的一个方法。
Servlet Filter不可能为其他地方提供AOP interceptor plugin entry.

所以，严格意义讲，这类设计仍然属于OO设计。属于同一个类体系的，统一入口控制。
而不是AOP的能够横跨所有类体系，类方法的那种全能目标。