Monthly Archives: August 2008

用URL作为资源,实现可配置的权限管理 — 这样真的好吗?

    用URL作为资源的意思是:将  访问某URL 定义为一个权限,只有拥有了该权限的用户,才可以请求该URL。

   这样做的好处是:

     1.实现可配置的权限管理。也就是说URL资源不必写死,可在生产环境中修改。

     2.还可以将权限逻辑从业务逻辑中提成出来 —- 代码里不用判断权限,在后台配一下即可,以后改变权限逻辑时,也不需要修改代码

   这两个好处是确切的,但是它在发布时存在一定的负面作用:

     1.url定义要么在后台界面手动配,要么写在配置文件里,要么作为SQL写到数据库中。这些东西不是高级语言代码,没法用编译器防止“语法”错误,因此出错率很高

     2.开发人员在开发调试时,一般会写一个功能,配一个权限,由于耐心、急躁等因素,等功能全部完成时,权限定义的配置却没有统一记录,等到系统测试时才恍然大悟!

     3.由于测试环境和生产环境的不同,权限定义从测试移到生产之前,往往要做很多改动才行,这也增加了出错率,提高了烦恼程度

     4.一个系统中, URL定义 一般会有很多, 本身维护起来就麻烦

XFireClientFactoryBean的lookupServiceOnStartup属性

XFireClientFactoryBean的lookupServiceOnStartup属性应配置为false

目的在于:在系统启动时,spring不立即查找远程的服务Bean,而在请求该服务时查找

这是为了避免:如果系统启动时不能访问远程服务,系统就无法成功启动,以致崩溃

<bean id="xxxService"
  class="org.codehaus.xfire.spring.remoting.XFireClientFactoryBean">
  <property name="serviceClass">
   <value>
    XXXService
   </value>
  </property>
  <property name="wsdlDocumentUrl">
   <value>
    http://xxx/pxxx.ws?wsdl
   </value>
  </property>
  <property name="lookupServiceOnStartup">
   <value>false</value>
  </property>
 </bean> 

PEAA_学习笔记_Concurrency

Two issuses about concurrency that’re difficult to handle: 

   1. offline concurrency(transcations among several databases or serveral requests)

   2. multi-thread concurrency in application server side

Two basic ways of controlling concurrency

   1. isolation

   2. to make some data immutable

Optimistic Lock: detect conflictions and then solve them。 The lock is only held during the commit

Pessimistic Lock:  prevent conflictions

业务层对表现层提供的服务应该是Application Service

     业务层对表现层提供的服务应该是Application Service,而不是Business Service

     以博客为例, 有一个Business Service可能是 getPostById(),即ID找到某篇文章;而它对应的App Service则应该是 visitPostById()。两者看上去没什么区别,但实际上 visit post比起简单的 get post 可能要复杂一些,比如验证、授权、增加博客访问次数等,如果直接将getPostById()方法提供给表现层,那么刚才提到的附加工作就要交给表现层来做,这无疑将加重表现层的代码重复,减弱业务层的代码重用。 因此,App Serivce 和 Biz Service应该区分为不同的模块。

 

     这也是 Application Service 模式(Core J2EE Patterns)的要求。Application Service 是直接跟 use-case一致的服务接口,而Business Service则要稍微通用一些

  

   

PEAA_学习笔记_Layering

1.为什么要分层?

  a.分层可以使你将精力集中在某一层。比如FTP使用者和开发者不须要考虑物理层和数据链路层的细节。如果不分层,要学的就多了

  b.分了层,可以在保留服务接口的前提下更换实现的细节。

  c.分层可以将耦合限制在两层之间,不存在3-Players情形

  d.分层利于标准化,这样才能将不同厂商的零件组装在一起

  e.分层后,一个下层可以为多种上层使用,比如TCP可以为FTP用,也可以为HTTP用

2.注意Layer和Tier的区别。一般来说Layer基于逻辑的区分,而Tier基于物理上的区分。比如,我们有Presentation Layer, Domain Login Layer和Data Source Layer 三个Layer;在实际上只有两个Tier (可以译为“端”): 客户端和服务器

3.一般情况上可以将所有程序都放在服务端运行,客户端只用一个浏览器,这样最方便部署和升级;但是有时候也可以将部分程序放在客户端,这主要是出于响应速度和断线操作(responsiveness or disconnected operation)的考虑

附:Fowler的经典语录

a. One pretty absolute rule is that nothing should depend on the presentation

  

PEAA_学习笔记_Transaction Script

"Organize Business Logic by procedures that carry out what needs to be done in a transaction "

1.A transaction script organizes all its business logic as a single procedure, making calls directly to the DB all through a thin dao layer

2.When applying this pattern, try to separate business logic from the layered architechure

3. Two ways of implemention: define each transaction as a Commond object, or collect some related transactions into one class which gets global methods

4.Transaction Script pattern is said to be easy to understand, however, it’s only for simple logic.  It’s gettiing very complicated as business logic grows.  —–I don’t see that happen.