用URL作为资源的意思是：将 访问某URL 定义为一个权限，只有拥有了该权限的用户，才可以请求该URL。 这样做的好处是： 1.实现可配置的权限管理。也就是说URL资源不必写死，可在生产环境中修改。 2.还可以将权限逻辑从业务逻辑中提成出来 —- 代码里不用判断权限，在后台配一下即可，以后改变权限逻辑时，也不需要修改代码 这两个好处是确切的，但是它在发布时存在一定的负面作用： 1.url定义要么在后台界面手动配，要么写在配置文件里，要么作为SQL写到数据库中。这些东西不是高级语言代码，没法用编译器防止“语法”错误，因此出错率很高 2.开发人员在开发调试时，一般会写一个功能，配一个权限，由于耐心、急躁等因素，等功能全部完成时，权限定义的配置却没有统一记录，等到系统测试时才恍然大悟！ 3.由于测试环境和生产环境的不同，权限定义从测试移到生产之前，往往要做很多改动才行，这也增加了出错率，提高了烦恼程度 4.一个系统中， URL定义 一般会有很多， 本身维护起来就麻烦
跟displayTag相比，有下列优点： 1.提供表内搜索功能，不需要手工开发搜索程序 2.排序时是整表排序，而不是像displayTag那样只能页内排序
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>
这一节介绍了三种模式：Domain Object, Transaction Script 和 Table Module。 对第一种模式还不是非常明白，以后慢慢体会
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 …
An object that acts as a Gateway to a database table 与Row Data Gateway不同，它对应的不是表中的一行，而是整个表，所以它的方法可以都做成静态的
业务层对表现层提供的服务应该是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则要稍微通用一些
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
"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. …