Persistent Domain Objects Pattern

It provides a greater flexibility for the enterprise level applications. Benefit of this architecture is that we have to only change the DAL (Data Access Layer) when we change Database (i.e. to make other layers independent of Database), (and of course this depends on whether the changes are syntactic or semantic – if there is considerable semantic change, additions, (new tables, new fields)the applications change) and it allows to persisting domain objects Other advantage is that unit testing of each layer can be done separately. Also this architecture decouples the application and makes it more flexible. We used the same pattern in one of the project, below is the description for the same:

1) DAL (Data Access Layer): This layer retrieves the data from database.

2) Interface Later: DAL must implement interface layer to make sure that all required methods are implemented by DAL. This is very important when we have multiple DAL (i.e. when we have multiple databases).

3) Factory layer: This layer returns the object of DAL.

4) Business Layer: The business logic is implemented in this layer. This layer creates objects of DAL using Factory layer.

5) Presentation layer: This layer dealt with presentation of UI and binding of data with UI.

This Pattern gives a solution to separate and deal with the tight-coupling of the persistence and application logic code. It decouples both layers by extracting the details of the persistence implementation along with hiding it behind an interface.

Reference - Previous projects