"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. …
security, transaction management, pooling, caching, concurrency ,logging
大师l [13:00]: 标志文件有一般有2种功能，一种是表明此文件已传送完毕，一种是核对，即在文件内容写明传送文件的大小和条数 大师l [13:01]: 对于批处理来说，加上标志文件是必不可少的 菜鸟 [13:01]: 受教了 大师l [13:02]: 如果仅仅说明文件已传送完毕，可为空 大师l [13:06]: 标志文件肯定是需要的 菜鸟 [13:06]: 哦 大师l [13:07]: 如果他是轮询方式处理文件，你一传文件她就检测到文件，他就开始处理，可是你的文件还正在处理呢 大师l [13:08]: 如果文件是损坏的文件，他也不知道的
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
Aggregation […] is the typical whole/part relationship. This is exactly the same as an association with the exception that instances cannot have cyclic aggregation relationships (i.e. a part cannot contain its whole). Composition […] is exactly like Aggregation except that the lifetime of the ‘part’ is controlled by the ‘whole’. This control may be direct …
"Build an object model of the domain that incorporate both behavior and data"
业务层对表现层提供的服务应该是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则要稍微通用一些
区别就是当“实现”发生根本性的变更时（比如数据库平台更换导致SQL语句变更），如果直接使用实现类作为接口，则需要直接“修改”实现类的代码；而如果使用 接口 + 实现类 模式， 则只需“新建”一个实现类，并切换接口对应的实现（一般情况下这只需要修改配置文件）。 一般情况下，“修改”和“新建”并没什么区别，直接调用实现类的方法，并不需要知道方法内部的实现，其透明性和 接口 + 实现类 的模式是一样的；但如果考虑到一个软件机构的代码一致性的话，区别就很大了。对一个成熟的软件机构来说，同名（包括包名和类名）类文件的功能应该基本相同，虽然这些代码文件属于不同的系统。 如果BookDAO类在系统A中使用SQL SERVER，而在系统B中对应Oracle，这是很不合适的；而如果采用 接口 + 实现类 的模式， 可以将接口名称为BookDAO，而在两个系统中的实现类分别叫做BookDAOSqlServer和BookDAOOracle，这样就比较体面了
An object that acts as a Gateway to a single record in a data source 一个Domain Object对应一个Row Data Gateway 对象，这样可以将持久化逻辑从Domain Object中解耦出去
An object that acts as a Gateway to a database table 与Row Data Gateway不同，它对应的不是表中的一行，而是整个表，所以它的方法可以都做成静态的