Domain Layer Patterns

Transaction Script (data in -> transaction(do everything here) -> data out)

1. Organize Business Logic by procedures that carry out what needs to be done in a transaction;
2. A Transaction Script organizes all this logic primarily as a single procedure, making calls directly to the database or through a thin database wrapper. Each transaction will have its own Transaction Script, although common subtasks can be broken out into sub-procedures. Each Transaction Script is a public method on a class.

Domain Object

1. Build an object model of the domain that incorporate both behavior and data. Every object has its own behavior and state. And Objects incorporate each other, rather than that of the transaction script, which will do everything in a transaction.

Table Module

1. Provide a single object for all the behavior on a table
2. A Table Module organizes domain logic with one class per table in the database, so usually you need ID to pull out the specified row
3. It is fit into the GUI

MIX

1. With a dominant Transaction Script you have most of your domain logic in Transaction Scripts, and you have some common behavior in relatively simple domain objects.
2. A dominant Domain Model will have most logic in domain objects with just some coordination code in Transaction Scripts. The middle way here is the controller-entity style the names of which come from a common practice influenced heavily by [Jacobson et al]. The point here is to have any logic that's particular to a single transaction or use-case placed in Transaction Scripts, which are commonly referred to as controllers. These are different controllers to the input controller in Model View Controller or the Application Controller so I use the term use-case controller. Behavior that's used in more than one use case goes on the domain objects which are called entities.

 

转载于:https://www.cnblogs.com/ellipse-gao/archive/2007/05/25/759156.html