MyBatis know how much (4) business object model

Almost all well-structured software uses a layered design. Layered design divides an application into several cohesive parts based on technical functions, separating the implementation details of a particular technology or interface from the rest. Layered design can be implemented in any strong programming language. Figure 1-2 shows a typical high-level view, which is useful for many commercial applications.

Read as "dependent" or "used" in the arrows in the This layered design is actually derived from the Dimitri Law, which is a way of stating that "each layer should only have a limited understanding of the layers that are closely related to themselves." ”

Each layer is only "interacting" with its own direct underlying. This ensures that the dependency flow (dependency flow) has only one direction, thus avoiding the kind of pizza-style code that is very common in applications without layered design.

MyBatis is a persistent layer framework. The persistence layer is located between the business logic layer of the application and the database. This separation is important to ensure that the persistence strategy is not mixed with business logic code, and vice versa. The benefit of this separation is that your code will be easier to maintain because it allows the evolution of the object model to be independent of the database design.

While MyBatis focuses primarily on the persistence layer, it is important to understand each layer in the overall architecture of the application. Although it is possible to separate the concerns by layering the design so as to minimize the reliance on any particular implementation (or even none), it is naïve to think that this can be done regardless of the other layers ' presence, regardless of the interaction with the other layers. No matter how well the application is designed, you must understand that there must be some indirect behavioral correlation between layers and layers. The following sections discuss each layer of the application and the relationship of mybatis to those layers.

Business Object Model

A business object is the basis for all other parts of an application. It is a representation of the problem domain in object-oriented methodology, so the classes that make up the business object model are sometimes referred to as domain classes (domain Class). All other tiers Use the business object model to represent data and perform certain business logic functions.

The designers of the application usually start with the design of the business object model. Even at a higher level, the various classes defined in the business object model are derived from nouns in our problem domain. As applications become more complex, the class represents a more abstract concept.

The business object model classes can of course include some logic, but they must not contain any code that accesses other layers, especially the presentation and persistence layers. In addition, this business object model must never be dependent on any other layer. The business object model can be used by other tiers--but never in turn.

Persistent layers like MyBatis typically use business logic objects to represent the data stored in the database. These realm classes in the business object model will be the parameters and return values of the persistence method (persistence). It is for this reason that these classes are sometimes referred to as data transfer classes (data Transfer object, DTOs). Although data transmission is not their only function, from the perspective of the persistence framework, the name is quite appropriate.

Series Articles:

MyBatis know how much (1)

MyBatis know how much (2)

MyBatis know how much (3)

MyBatis know how (4) The advantages of MyBatis

MyBatis know how much (4) business object model