ASP. NET design Pattern Note Three: organization of the business logic layer

Highlights of this chapter:

1.Transaction Script mode organization business logic

2.Active record mode and Castle Windsor to organize business logic

3.Domain model mode to organize business logic

4.Anemic model and domain model to organize differences in business logic

5. Understanding domain-driven design ddd and how to use it to focus on business logic rather than infrastructure concerns

Not all applications are the same, and not all applications require complex architectures to encapsulate the business logic of the system. As a developer, it is important to understand the pros and cons of all domain logic patterns in order to design the most appropriate pattern.

Transaction Script

I don't have too much of a breath. It's all a process-oriented notation. So it is easiest to understand, master and use the pattern. It is common practice to create a separate method for each business transaction and combine them into some kind of static hypervisor or service class. Each process contains all the business logic required to complete a business transaction, including workflow, business rules, and database persistence validation checks.

Its advantages are easy to understand and get started.

The disadvantage is that once the program becomes larger or the business logic becomes complex, the number of methods becomes more numerous, thus creating a useless API that is filled with a fine-grained method of overlapping functions. The code will quickly become cumbersome and non-maintainable.

As this method is relatively simple, we do not need to show an example.

Active Record

The active record pattern is a popular pattern, especially when the underlying database model matches the business model. Typically, each table in the database corresponds to a business object. A business object represents a row in a table and contains data, behavior, and tools to persist the object, as well as the methods required to add new instances and find collections of objects.

In active record mode, each business object is responsible for its own persistence and related business logic.

The Active record pattern is ideal for simple applications that have a one-to-one mapping between the data model and the business model, such as blogs or forum engines. This is also a good pattern if you already have a database model or want to build your application with a "data first" approach . Because business objects have a one-to-one mapping to tables in a database and all have the same creation, read, update, and delete methods, you can use code generation tools to automatically generate business models. As with the transaction script mode, the Active record mode is simple and easy to master.

The active record pattern is popular with database-based Web applications, and one example is the Ruby on Rails framework, which combines the MVC pattern with the active record ORM. in the. net domain, the Castle ActiveRecord project, built on top of NHibernate, is one of the most popular open source active record frameworks . The following will demonstrate its specific usage by building a simple blog site that contains only a small amount of business logic and therefore has a good correlation between business objects and data models.