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 […]

业务层对表现层提供的服务应该是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. […]