Soudamini's blog

Domain Logic Patterns

1. Transaction Script:  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 into sub procedures. This pattern is useful when business logic is simple. Can use Table Data Gateway pattern for communicating with DB.
2. Domain module: An object model of the domain that incorporates both behavior and data. A Domain Model creates a web of interconnected objects, where each object represents some meaningful individual. Putting a Domain Model in an application involves inserting a whole layer of objects that model the business area. A simple domain model can use the Active record pattern and a complex domain model can use Data mapper pattern.
3. Table module: A single instance that handles the business logic for all rows in a database table or view. It organizes domain logic with one class per table in the database, and a single instance of a class contains the various procedures that will act on the data. The primary distinction with Domain Model is that, if you have many orders, a Domain Model will have one order object per order while a Table Module will have one object to handle all orders. Table Module is very much based on table-oriented data. it does not give the full power of objects in organizing complex logic. E.g. using a dataset in .NET
4. Service Layer: Defines an application’s boundary with a layer of services that establishes a set of available operations and coordinates the application’s response in each operation. The service layer can be kept locally or invoked remotely depending on the need. Invoking remotely can affect performance. Remote façade pattern can be used for remotely accessing the service. This pattern is useful when we have multiple clients using the service.

Data source architectural Patterns

1. Table data gateway: An object that acts as a Gateway to a database table. One instance handles all the rows in the table. A Table Data Gateway holds all the SQL for accessing a single table or view: selects, inserts, updates, and deletes. It works well for Table Module and Transaction script. In .NET  the dataset can be used for this pattern.
2. Row data gateway: An object that acts as a Gateway to a single record in a data source. There is one instance per row. This pattern is similar to the active record pattern. But active record pattern holds business logic. This works well for Transaction script. This can be used along with data mapper for a better design. If used with transaction script we find lot of code duplication. Moving the logic gradually generates the Active record pattern.
3. Active record: An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data. It is similar to Row Data Gateway. The difference is that it contains domain logic along with data access. The Active Record class typically has methods that do the following. Construct an instance of the Active Record from a SQL result set row, Construct a new instance for later insertion into the table, Static finder methods to wrap commonly used SQL queries and return Active Record objects, Update the database and insert into it the data in the Active Record, Get and set the fields, Implement some pieces of business logic.
4. Data Mapper: A layer of Mappers that moves data between objects and a database while keeping them independent of each other and the mapper itself. The primary occasion for using Data Mapper is when you want the database schema and the object model to evolve independently. To work on transactions Unit of Work pattern can be used. Identity map pattern can be used for find operations and to minimize impact on in memory objects lazy load pattern can be used along with this. We can have an in memory representation of the data. While finding a particular record first the in memory version should be checked before making a round trip to the DB.

Object Relational Behavioral Patterns

1. Unit of Work: Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems (uses optimistic & pessimistic offline locks). When an object is changed a dirty flag can be maintained for completing the transaction.
2. Identity Map: Ensures that each object gets loaded only once by keeping every loaded object in a map. Looks up objects using the map when referring to them. It acts as a cache for database reads, which means that you can avoid going to the database each time you need some data. The Identity map can be a session specific object or can be part of the unit of work.
3. Lazy Load: An object that doesn’t contain all of the data you need but knows how to get it. There are four main ways you can implement Lazy Load: lazy initialization, virtual proxy, value holder, and ghost. In lazy initialization, we check for null value and load it. This enforces a dependency between the object and the DB. So to avoid this virtual proxy can be used. Here the proxy is an empty object. On a method call like get is called the object is loaded. The demerit of this approach is that we may need to maintain multiple virtual proxies for the same object which can lead to identity problem. To overcome this problem Value holder can be used (A concept from Small talk). A ghost is the real object in a partial state. When you load the object from the database it contains just its ID. Whenever you try to access a field it loads its full state. Inheritance often poses a problem with Lazy Load. If you’re going to use ghosts, you’ll need to know what type of ghost to create, which you often can’t tell without loading the thing properly. Virtual proxies can suffer from the same problem in statically typed languages. Another danger with Lazy Load is that it can easily cause more database accesses than you need.