Elaborate business logic (ii)

3. Architecture mode and implementation of business logic

Martin Fowler, in the book Patterns of enterprise Application Architecture, summarizes the organization of business logic in four enterprise applications: Transcation Script,domain Model,table module and service Layer, in addition, the tenth chapter of the book "Data Source Architecture Patterns" contains a pattern--active Record. With the recent development of software architecture and personal understanding, I prefer to put active record into the organizational mode of business logic, and service layer should not be considered as a pattern peculiar to business logic, so in this article, we will introduce four modes: Transcation Script , Table module,active record and domain Model.

3.1. Transction Script

3.1.1, overview

Transction Script (hereinafter referred to as TS) is a process-oriented approach to business logic organization. The first thing to emphasize here is that the word transction here has no connection to the transction in the database system that represents "transaction". ts is the decomposition of the business in the domain into a business process, each process to achieve a business function, specific to the program, a business process is often mapped to a method. TS is a fully process-oriented business organization model, suitable for applications where business logic is simpler.

It should be said that the vast majority of systems we see are organized in TS business. Examples are classic such as PetShop and Oxite. Sometimes for ease of maintenance, developers will focus on the same domain entity-related business methods into one class, although the concept of domain entities and classes is used, but it has nothing to do with object-oriented, it is completely process-oriented.

When using TS, it is possible to embed data manipulation execution code (such as code that executes SQL or stored procedures) directly in the business method without requiring a data access layer, sometimes to write a helper class to encapsulate the database for reusability and maintainability. Of course, this is not to say that TS can not be used with the data access layer, but due to the application of TS general business is very simple, if used in conjunction with repository or ORM, the business logic layer will tend to become very "thin", it seems to be only the data Access layer encapsulation. Generally in need to support multi-database occasions, to cooperate with repository and Abstract factory use.

TS is shown below:

Figure 3-1, transcation script schema schematic

As you can see, in TS, the business layer has no object-oriented stuff. Classes may be used, but the classes are just the modules that organize the business methods, each of which has a business approach, each of which completes a business process and is organized entirely in a process-oriented structure.

3.1.2, Analysis

• When can I use TS?

It should be said that if you have one of the following conditions, you can consider TS:

1) The system business is very simple and intuitive, and the likelihood of frequent changes is small

2) The duration is very tight, need to compress the design time as soon as possible to put the code

3) Unable to master and use OO for system design and development

4) aversion to Oo, is like the process-oriented

• What are the advantages of TS?

1) The design stage input is small, the start-up cost is low. Because TS is easier to master and uses a low starting point, fewer initial inputs using TS

2) In the case of simple and intuitive business, the code of TS structure is intuitive and easy to understand, with good maintainability

• What are the disadvantages of TS?

1) Easy to create code redundancy. Because each business organizes its own processes, it reduces the chance of reuse and may produce repetitive code

2) because TS is inherently unsuitable for business complex systems, business layer code can be complicated when the system is more complex

3.2. Table Module

3.2.1, overview

The Table Module (tm) is also a process-oriented business logic organization, unlike TS, where the TM is closer to the relational database structure. In TS, data representations and passes are generally used, such as DTOs, which are generally focused on a single object. The TM generally organizes the business module according to the data table, each module corresponds to a table, which contains the corresponding processing of the table. And in the business layer, using the Library-table structure of the object for data manipulation, to maximize the correspondence with the data table. Business organizations generally follow process-oriented organization.

In general, when the business is relatively simple and the business is basically focused on crud operations, you can consider TM. Using a TM means using a data-driven design. Generally, it is difficult to implement a library of library-table structure operation objects, so the platform used should include such a set of libraries when TM is generally chosen. such as the. NET platform on the built-in rich library-table operation, Dataset,datatable,dataadapter, etc. in the implementation of the TM architecture can play a very convenient role.

After using a TM, it is generally not necessary to mate with reponsitory or ORM, because the business layer at this time is also oriented towards process and relational-oriented structures without mapping.

The TM is as follows:

Figure 3-2, Table module architecture schematic

After using the TM, the business code often has a variety of objects corresponding to the database of libraries, tables, records, fields and other elements, and provide similar relational database operations.

3.2.2, analysis

• When can I use TM?

You can consider a TM if both of the following conditions are true:

1) The system business is more intuitive, the crud operation is relatively centralized

2) The entire development of the guiding ideology is data-driven

3) The selected platform has a mature library-table Operation Library Support

• What are the advantages of TM?

1) Data manipulation methods like relational databases are intuitive, making it simple and efficient to design and write data manipulation functions

• What are the drawbacks of TM?

1) TM needs complete data-driven, from the business to the UI to pass, storage data should be in the form of table structure, resulting in a degree of inflexible

2) When the business is not a crud centralized operation, especially when the domain model and the database table model differ greatly, it is very difficult to use the TM organization business

3.3. Active Record

3.3.1, overview

An Active Record (hereinafter referred to as AR) is an object-oriented approach to business logic organization. AR is applicable to the design of object-oriented thinking in the case of simple business. Its basic idea is to abstract each entity in the domain into a business class (BO) and then encapsulate the data and behavior of the entity into the properties and methods of the class. In particular, the CRUD functionality is also encapsulated in Bo. In other words, Bo in AR has both business method and persistence function. It has the characteristics of ORM, and it has to deal with the problem of correlation between entities.

When using AR, it is generally better to have the appropriate framework to support, otherwise completely hand-implemented AR a little trouble. As with the AR function in the Castle framework, Linq to SQL also has the meaning of AR. After using AR, it is generally not necessary to use the data access layer alone.

The structure of AR is as follows:

Figure 3-3, Active record schema schematic

As can be seen from Figure 3-3, AR has a simple oo abstraction of the business domain, which abstracts the entities into AR business objects, and the AR business objects contain data, business methods and data access related ORM methods. In addition, the AR business object maintains simple one-to-many and many-to-many relationships between entities.

3.3.2, analysis

• When can I use AR?

You can consider AR if both of the following conditions are true:

1) The system business is more intuitive

2) Want to try to use or accustomed to the use of OO system design and implementation

3) A mature AR frame on the platform can be used

• What are the advantages of AR?

1) design and implementation using OO to avoid redundant code problems to a certain extent

2) After using AR, the data and business related to an entity are all concentrated in the AR business object, the module cohesion is good, easy to maintain

3) practice proves that the business layer coding efficiency of AR structure is very high

• The disadvantages of AR?

1) AR still needs to focus on the correlation between data, to some extent with data tables and shadows, not completely out of the data-driven, so when the business domain and database structure gap is large, the implementation of difficulties

2) AR crud is individual-size, when the bulk operation, such as thousands of data at a time, if strictly respected from AR will need to generate thousands of AR business objects, this is a disaster. Therefore, in the case of large-scale queries, you can consider using TS mate AR

3) If the business is very complex, AR will be unable to

3.4. Domain Model

3.4.1, overview

Domain Model (hereinafter referred to as DM) is an object-oriented business logic organization that is suitable for domain-driven and business-organized operations for complex business systems. The previous three architectures have one common disadvantage-they are not suitable for complex business systems. So what is complexity and what is simple? I'm sorry, I can't give a definitive answer, and I reckon it's hard for anyone in the world to give a standard, uncontested answer. Because the complexity and simplicity of the software system itself is a difficult to quantify indicators, many times, only rely on professional experience.

I personally estimate that 95% of the world's software systems will not be more difficult to operate beyond the capabilities of the above three models, and if you unfortunately encounter the remaining 5%, I am afraid that only domain model can help you now. domain model is a purely object-oriented business architecture model, and its core idea is to acquire various entity abstractions in the domain and then model and run them exactly as they are in the real world. And the business object is "persistent ignorance". There is a fine discussion under "persistent ignorance". This model is very complex and difficult to master, but once mastered and used, its ability will definitely exceed your imagination.

Here's a look at the DM architecture:

Figure 3-4, Domain model architecture schematic

As can be seen from figure 3-4, DM seems to be a very tangled pattern, and in fact, it is really tangled! In fact, I think that if you can master and use DM to organize business logic, that person is definitely the master of the architect (I can't do it now).

First of all, we will analyze the main points of DM with the diagram.

First, the business object in DM is the pure business object, which does not contain data access operation. This can be compared with the business object in AR. In other words, the business objects in the DM are purely business objects, and they focus only on the implementation of the business.

Second, the DM of the organization of many objects, the relationship is complex, and this relationship is no longer just that simple pair of one or one-to-many relationship, but the domain of various dependencies and association of the abstract, the relationship type is many, very complex.

Third, DM needs the business part of "persistent ignorance". The so-called persistent ignorance refers to the business segment that simply executes business functions without having to persist in relationships. When using DM, a set of ORM mechanisms must be designed (note that the word "mechanism" is used instead of "frame" or "library"), so that data persistence is performed automatically when necessary when the business system is running. This is why the arrows between the data source and the business layer are dashed.

As mentioned above, DM is to maximize the simulation of the reality. The biggest difference between the real world and the software world is that the real world is "memory infinite, never stop", can think of the real world in an infinite memory never stopped running program. And the software world is different, its memory is limited, we can not put all the objects in memory, and once the power down, it will stop running, because of this, we need a persistence mechanism to cooperate with DM simulation of the real world. To bring the business closer to reality, it must have no sense of the persistence process. And a set of persistent mechanism silently for it to create a like memory infinite, never stop environment, so DM can play the power.

Four, DM often need services layer of cooperation. Because DM has only one business object inside, they call each other, and do not provide a friendly interface to interact with the UI, so when using DM, the various UI needs are often encapsulated (review facade mode), forming a services Layer to facilitate interaction with the UI.

3.4.2, analysis

• When can I use DM?

If you have the following conditions, you can consider the DM:

1) system business is extremely complex

2) Solid and experienced proficient in OO architecture and designers

3) project funding and time adequacy

4) Implement field-driven design

• What are the advantages of DM?

1) Full use of OO ideas will enable you to enjoy all the advantages of OO

2) Powerful killer to handle complex business. If the DM is used properly, it will enable complex business to be efficiently solved

• The disadvantage of DM?

1) The use of the threshold is very high, very difficult, if the team is not proficient in OO and system architecture and experienced experts difficult to implement

2) The design process is extremely complex and can lead to design paralysis

3) How to design a good ORM mechanism to assist DM is a big problem

3.5. Comparison and selection of various architectural models

I believe that after reading the above, you must have a clear understanding of various business organization models and their characteristics, pros and cons, application scenarios, if I am here to chatter about the comparison of various models and how to choose, it is inevitable to insult you IQ suspicion O (∩_∩) o~, so here I only present a decision-making network Diagram, In order to play a carding and summarize the role.

Figure 3-5, Business architecture Model decision Network

(Solemnly declare: Figure 3-5 is my original, not excerpts from the literature, so this chart selection process represents only personal opinion.) Due to the limited level of the author, can not guarantee that this diagram must be reasonable and correct. So in the actual selection, please refer to a lot of literature and consulting experts, this figure only summarizes and discusses the role, not as any guidance and norms. The author shall not be liable for any economic and other losses incurred by the project as a result of following this chart selection. )

4. Concluding remarks

This article has introduced the definition of business logic, related theories and the classical business logic related architecture pattern through the space of two articles. In this paper, many existing theories are elaborated, and many personal understandings and opinions are also doped. Therefore, please read more critically absorbed, while referring to the classical literature and bibliographic comprehensive understanding of business logic, do not just look at my opinion.

In addition, as this article is only a summary of the article, can not be named in all aspects of business logic, in depth is also basically a shallow. Therefore, if you want to understand the business logic in depth, you can see the relevant classic books and literature.

This article reprinted to: http://kb.cnblogs.com/page/50527/

Elaborate business logic (ii)