copyright from: www.dsoftworld.com
Business Logic Layer
The business logic layer is an abstract layer that contains all the rules, workflow and validation that define and deal with the business complexities that your software has been designed to meet. Typically, the business logic layer will fit between your user interface, service, or presentation layer and your data access layer. By separating the business logic from other layers in your applications you are separating your concerns and keeping your code loosely coupled and allowing for different implementations to be used with the business logic layer; for example, changing the UI from a web application to a WPF application.
WPF Win Forms --- Web Forms --- Other Services
-------------------------------------------------------------------
Service Layer
-------------------------------------------------------------------
Business Logic Layer
-------------------------------------------------------------------
Data Access Layer
-------------------------------------------------------------------
Data Sources
Depending on the complexities of the business model that your application has been designed for, the structure of your business logic layer may differ considerably. For instance a complex banking application will have a rich Domain Model that represents the real banking domain with hundreds of small business entities representing loans, customers, and accounts. For a simpler application, such as a blogging engine, you may have a number of fairly simple business objects that map very closely to your underlying Data Model with little or no business logic, simply acting as a method to add and retrieve data. In the next section, you will look at the various patterns at your disposal to structure your business logic layer.
Patterns for Your Business
There are a number of design patterns that you can follow that will help you to organize your business logic. In the below part, you will be introduced to three of the main patterns found in the business logic layer: the Transaction Script, Active Record, and the Domain Model pattern.
Transaction Script
Transaction Script is a very simple business design pattern, which follows a procedural style of development rather than an object - oriented approach. Simply create a single procedure for each of your business transactions with each procedure containing all of the business logic that is required to complete the business transaction from the workflow, business rules, and validation checks to persistence in the database.
One of the strengths of the Transaction Script pattern is that it is very simple to understand and clear to see what is going on without any prior knowledge of the pattern. If a new business case needs to be handled, it is straightforward enough to add a new method to handle it, which will contain all of the related business logic.
The problems with the Transaction Script pattern are revealed when an application grows and the business complexities increase. It is very easy to see many management or application classes with hundreds of fine - grained transaction methods that map directly to a business use cases. Sub methods can be used to avoid repetitive code such as the validation and business rules, but duplication in the workflow cannot be avoided, and the code base can quickly become unwieldy and unmanageable as the application grows.
If you have a simple application with minimal business logic, which doesn’t warrant a fully object - oriented approach, the Transaction Script pattern can be a good fit. However, if your application will grow, you may need to rethink your business logic structure and look to a more scalable pattern like the Active Record pattern.
Active Record Pattern
The Active Record pattern is very popular pattern and is especially effective when your underlying database model matches your business model. Typically, a business object will exist for each table in your database.
The Active Record pattern is great for very simple applications where there is a one-to-one mapping between the Data Model and the Business Model, such as with a blogging or a forum engine; it ’ s also a good pattern to use if you have an existing database model or tend to build applications with a “ data first ” approach. Because the business objects have a one - to - one mapping to the tables in the database and all have the same CRUD (create, read, update, and delete) methods, it ’ s possible to use code generation tools to auto - generate your business model for you. Good code gen tools will also build in all of the database validation logic to ensure that you are allowing only valid data to be persisted.
However, the Active Record pattern is no silver bullet. It excels with a good underlying Data Model that maps to the business model, but when there is a mismatch, sometimes called an impedance mismatch, the pattern can struggle to cope. This is the result of complex systems sometimes having a very different conceptual business models than the Data Model. When there is a rich business domain with lots of complex rules, logic, and workflow, this favors going with the Domain Model approach.
Domain Model Pattern
You can think of a Domain Model as a conceptual layer that represents the domain you are working in. Things exist in this model and have relationships to other things. What do I mean by things? Well, for example, if you were building an e - commerce store, the “things” that would live in the model would represent a Basket, Order, and Order Item, and the like. If you were creating a loan application, you would have representations for a Borrower, Loan, Assets, and Debts. It’s these things that have data and, more importantly, behavior. Not only would an order have properties that represent a creation date, status, and order number, but it would also contain the business logic to apply a voucher to, including all of the domain rules that surround it — Is the voucher valid? Can the voucher be used with the products in the basket? Are there any other offers in place that would render the voucher invalid, and so forth. The closer your Domain Model represents the real domain the better, as it will be easier for you to understand and replicate the complex business logic, rules, and validation process.
The main difference between the Domain Model and the Active Record pattern is that the business entities that live in the Domain Model have no knowledge of how to persist themselves, and there doesn’t necessarily need to be one - to - one mapping between the Data Model and the Business Model.
As mentioned earlier, the Domain Model, unlike the Active Record pattern, has no knowledge of persistence. The term persistence ignorant (PI) has been coined for the plain nature of the POCO(plain old common runtime object) business entities. How then do you persist a business object with the Domain Model?
Typically, the repository pattern is used. When you are employing the Domain Model pattern, it’s the responsibility of the Repository object, along with a data mapper, to map a business entity and its object graph of associated entities to the Data Model. Be aware that business entities inside the Domain Model are PI.
Trying to solve complex business problems in software is difficult, but when using the Domain Model pattern, you first create an abstract model of the real business model. With this model in place, you can then model complex logic by following the real domain and recreating the workflow and processing in your Domain Model. Another advantage that a Domain Model holds over the Transaction Script and the Active Record patterns is that, because it contains no data access code, it can be easily unit tested without having to mock and stub out dependencies of such a data access layer.
Again, the Domain Model pattern may not always be a great fit for your application needs. One of its great strengths is dealing with complex business logic, but a full - blown Domain Model is architectural overkill when very little business logic is contained within the application. Another disadvantage of the pattern is the steep learning curve needed to become proficient in it compared to the Active Record and Transaction Script options. To use the pattern effectively takes time and experience and, most importantly, a sound knowledge of the business domain you are trying to model.
Which Pattern to Use?
Each pattern has its pros and cons, and there is no one method that will suit all of your development needs. Let’s take a brief look at each pattern and see when it’s most appropriate to use it.
Transaction Script: If you have a simple application with little or no logic, then Transaction Script is a great choice as a straightforward solution that is easily understood by other developers picking up your code down the line.
Active Record : If your business layer is simply a thin veil over the top of your database, then this is a great pattern to opt for. There are many code generation tools that can automatically create your business objects for you based on your database schema, and it ’ s not too difficult to create your own.
Domain Model : The Domain Model excels when you have an involved, rich complex business domain to model. It’s a pure object - oriented approach that involves creating an abstract model of the real business domain and is very useful when dealing with complex logic and workflow.
The Domain Model is persistence ignorant and relies on mapper classes and the Repository pattern to persist and retrieve business entities.
It now your decision how to implement your application’s Middleware. But keep in mind that a good design will calculate the support time and application extensibility.
Stay tuned for more, and share it with your Development cycle.
Business Logic Layer
The business logic layer is an abstract layer that contains all the rules, workflow and validation that define and deal with the business complexities that your software has been designed to meet. Typically, the business logic layer will fit between your user interface, service, or presentation layer and your data access layer. By separating the business logic from other layers in your applications you are separating your concerns and keeping your code loosely coupled and allowing for different implementations to be used with the business logic layer; for example, changing the UI from a web application to a WPF application.
WPF Win Forms --- Web Forms --- Other Services
-------------------------------------------------------------------
Service Layer
-------------------------------------------------------------------
Business Logic Layer
-------------------------------------------------------------------
Data Access Layer
-------------------------------------------------------------------
Data Sources
Depending on the complexities of the business model that your application has been designed for, the structure of your business logic layer may differ considerably. For instance a complex banking application will have a rich Domain Model that represents the real banking domain with hundreds of small business entities representing loans, customers, and accounts. For a simpler application, such as a blogging engine, you may have a number of fairly simple business objects that map very closely to your underlying Data Model with little or no business logic, simply acting as a method to add and retrieve data. In the next section, you will look at the various patterns at your disposal to structure your business logic layer.
Patterns for Your Business
There are a number of design patterns that you can follow that will help you to organize your business logic. In the below part, you will be introduced to three of the main patterns found in the business logic layer: the Transaction Script, Active Record, and the Domain Model pattern.
Transaction Script
Transaction Script is a very simple business design pattern, which follows a procedural style of development rather than an object - oriented approach. Simply create a single procedure for each of your business transactions with each procedure containing all of the business logic that is required to complete the business transaction from the workflow, business rules, and validation checks to persistence in the database.
One of the strengths of the Transaction Script pattern is that it is very simple to understand and clear to see what is going on without any prior knowledge of the pattern. If a new business case needs to be handled, it is straightforward enough to add a new method to handle it, which will contain all of the related business logic.
The problems with the Transaction Script pattern are revealed when an application grows and the business complexities increase. It is very easy to see many management or application classes with hundreds of fine - grained transaction methods that map directly to a business use cases. Sub methods can be used to avoid repetitive code such as the validation and business rules, but duplication in the workflow cannot be avoided, and the code base can quickly become unwieldy and unmanageable as the application grows.
If you have a simple application with minimal business logic, which doesn’t warrant a fully object - oriented approach, the Transaction Script pattern can be a good fit. However, if your application will grow, you may need to rethink your business logic structure and look to a more scalable pattern like the Active Record pattern.
Active Record Pattern
The Active Record pattern is very popular pattern and is especially effective when your underlying database model matches your business model. Typically, a business object will exist for each table in your database.
The Active Record pattern is great for very simple applications where there is a one-to-one mapping between the Data Model and the Business Model, such as with a blogging or a forum engine; it ’ s also a good pattern to use if you have an existing database model or tend to build applications with a “ data first ” approach. Because the business objects have a one - to - one mapping to the tables in the database and all have the same CRUD (create, read, update, and delete) methods, it ’ s possible to use code generation tools to auto - generate your business model for you. Good code gen tools will also build in all of the database validation logic to ensure that you are allowing only valid data to be persisted.
However, the Active Record pattern is no silver bullet. It excels with a good underlying Data Model that maps to the business model, but when there is a mismatch, sometimes called an impedance mismatch, the pattern can struggle to cope. This is the result of complex systems sometimes having a very different conceptual business models than the Data Model. When there is a rich business domain with lots of complex rules, logic, and workflow, this favors going with the Domain Model approach.
Domain Model Pattern
You can think of a Domain Model as a conceptual layer that represents the domain you are working in. Things exist in this model and have relationships to other things. What do I mean by things? Well, for example, if you were building an e - commerce store, the “things” that would live in the model would represent a Basket, Order, and Order Item, and the like. If you were creating a loan application, you would have representations for a Borrower, Loan, Assets, and Debts. It’s these things that have data and, more importantly, behavior. Not only would an order have properties that represent a creation date, status, and order number, but it would also contain the business logic to apply a voucher to, including all of the domain rules that surround it — Is the voucher valid? Can the voucher be used with the products in the basket? Are there any other offers in place that would render the voucher invalid, and so forth. The closer your Domain Model represents the real domain the better, as it will be easier for you to understand and replicate the complex business logic, rules, and validation process.
The main difference between the Domain Model and the Active Record pattern is that the business entities that live in the Domain Model have no knowledge of how to persist themselves, and there doesn’t necessarily need to be one - to - one mapping between the Data Model and the Business Model.
As mentioned earlier, the Domain Model, unlike the Active Record pattern, has no knowledge of persistence. The term persistence ignorant (PI) has been coined for the plain nature of the POCO(plain old common runtime object) business entities. How then do you persist a business object with the Domain Model?
Typically, the repository pattern is used. When you are employing the Domain Model pattern, it’s the responsibility of the Repository object, along with a data mapper, to map a business entity and its object graph of associated entities to the Data Model. Be aware that business entities inside the Domain Model are PI.
Trying to solve complex business problems in software is difficult, but when using the Domain Model pattern, you first create an abstract model of the real business model. With this model in place, you can then model complex logic by following the real domain and recreating the workflow and processing in your Domain Model. Another advantage that a Domain Model holds over the Transaction Script and the Active Record patterns is that, because it contains no data access code, it can be easily unit tested without having to mock and stub out dependencies of such a data access layer.
Again, the Domain Model pattern may not always be a great fit for your application needs. One of its great strengths is dealing with complex business logic, but a full - blown Domain Model is architectural overkill when very little business logic is contained within the application. Another disadvantage of the pattern is the steep learning curve needed to become proficient in it compared to the Active Record and Transaction Script options. To use the pattern effectively takes time and experience and, most importantly, a sound knowledge of the business domain you are trying to model.
Which Pattern to Use?
Each pattern has its pros and cons, and there is no one method that will suit all of your development needs. Let’s take a brief look at each pattern and see when it’s most appropriate to use it.
The Domain Model is persistence ignorant and relies on mapper classes and the Repository pattern to persist and retrieve business entities.
It now your decision how to implement your application’s Middleware. But keep in mind that a good design will calculate the support time and application extensibility.
Stay tuned for more, and share it with your Development cycle.
No comments:
Post a Comment