springboot: Can PO, VO, DAO, BO, DTO, POJO be distinguished?

Domain Model Naming Convention:

• Data object: xxxDO, where xxx is the name of the data table
• Data transfer object: xxxDTO, where xxx is the name related to the business domain.
• Display object: xxxVO, where xxx is generally the name of the web page.
• POJO is the collective name of DO/DTO/BO/VO, and it is forbidden to name it as xxxPOJO.

PO、VO、DAO、BO、DTO、POJO

• PO (Persistent Object): A persistent object used to represent data records in the database, usually corresponding to the structure of the database table, for CRUD (create, read, update, delete) operations.
• VO (Value Object): Value object, used to represent data objects in business logic, usually used to transfer data between layers.
• DAO (Data Access Object): Data Access Object, used to encapsulate data access logic, hide the underlying data storage details, and provide a set of methods for manipulating data.
• BO (Business Object): Business object, used to encapsulate business logic, usually reflects business processes or business entities. BO can use DAO and DTO for data manipulation and transmission.
• DTO (Data Transfer Object): Data transfer object, used to transfer data between system layers, usually contains multiple fields, and can be used to transfer data in batches.
• POJO (Plain Old Java Object): A simple Java object is a specific type of class without any restrictions or additional conditions, and can be used to represent various data.

It should be noted that the specific definitions of these acronyms may vary from project to project, so they should be used according to team agreement and actual needs in specific projects.

Hierarchical Domain Model Specification

Hierarchical domain model specification is a design pattern commonly used in software development, which divides the entire system into multiple levels, and each level is responsible for processing different tasks. The following are a few key concepts in the specification of a hierarchical domain model:

1. Domain Layer (Domain Layer): Responsible for defining business logic and data persistence operations, and providing APIs for use by other application layers.
2. Application Layer: Responsible for coordinating the interaction between the domain layer and the presentation layer, and exposing business logic to the presentation layer by defining service interfaces.
3. Presentation Layer: Responsible for presenting data to the user and passing user input to the application layer for processing.
4. Data Access Layer (Data Access Layer): Responsible for interacting with the database, including operations such as reading, writing, updating, and deleting.

In practice, the Hierarchical Domain Model Specification can have different variants. For example, you can combine the application layer and the presentation layer, or you can mix the data access layer and the domain layer. In summary, this design pattern aims to improve the maintainability, scalability and testability of the code, making the system easier to understand and modify.

PO: (persistent object), persistent object

PO (Persistent Object) refers to an object that always exists during the running of the program. Unlike temporary objects (Transient Object), they will be destroyed after the program execution is completed. Persistent objects typically interact with a database and can be stored and retrieved.

In object-oriented programming, persistence refers to saving the state of an object to a non-volatile storage medium so that the state of the object can be restored after the program ends. Persistent objects are a special kind of objects that are persistent, that is, their state can be permanently saved. This enables the program to restore its previous state after the program has been closed and restarted.

In practical applications, we can simplify the persistence operation by using the ORM (Object-Relational Mapping) framework. The ORM framework hides the details of the underlying database, allowing developers to access and manipulate data in an object-oriented manner, improving the readability and maintainability of the code.

It can be regarded as a java object mapped to a table in the database. It is a good choice to use Hibernate to generate PO.

VO:(value object), value object

VO (Value Object), also known as value object, refers to an immutable object composed only of attribute values. Its main function is to describe a specific domain concept, such as date, time, currency, etc., or some composite data structures.

Unlike PO (Persistent Object), VO does not have persistence capabilities. They are usually used to encapsulate values ​​or data for delivery and processing in applications. VO objects are usually designed to be immutable, which means their state cannot be modified, thus ensuring object consistency and reliability.

Value objects typically have the following characteristics:

1. Immutability: Once a value object is created, its state will never change, and all properties are read-only.
2. No identity: Equality of value objects is determined through their properties, which have no unique identifiers.
3. Can be shared: multiple objects can refer to the same value object because their state is immutable.

In practice, value objects are often used to encapsulate some simple, basic data types, such as strings, numbers, etc., and some complex data structures, such as collections, lists, trees, etc. Value objects can increase the readability and maintainability of code, while reducing the chance of errors.

It is usually used for data transfer between business layers, and like PO, it only contains data. But it should be an abstract business object, which can correspond to the table or not, depending on the needs of the business.

PO can only be used in the data layer, and VO is used in the business logic layer and presentation layer. Each layer operates its own data objects, which can reduce the coupling between layers and facilitate the maintenance and expansion of the system in the future.

DAO: (Data Access Objects), data access object interface

DAO (Data Access Objects) is a data access object interface, which provides access to a specific data source (such as relational databases, text files, etc.). DAO is often used to separate the underlying data storage details from the upper-level business logic, thereby improving code reusability and maintainability.

The DAO interface mainly includes the following aspects:

1. CRUD operation: The DAO interface provides basic data operation methods such as adding, deleting, modifying and checking. These methods usually involve operations such as the construction of SQL statements, parameter type conversion, and mapping of result sets.
2. Transaction control: The DAO interface can provide support for methods that require transaction control in business logic. Transaction control can ensure data consistency and reliability.
3. Exception handling: The DAO interface should be able to handle exceptions raised by the underlying data storage, and pass the exceptions to the caller for appropriate handling.
4. Abstraction: The DAO interface enables business logic to be implemented independently of specific data storage, thereby improving code portability and testability.

In practical applications, we can simplify the implementation of DAO by using the ORM (Object-Relational Mapping) framework. The ORM framework can automatically generate SQL statements, map query results and other operations, thereby reducing the workload of developers. At the same time, when designing the DAO interface, factors such as data storage security and performance need to be considered to ensure that the application can run normally and adapt to changing business needs.

BO: (Business Object), business object layer

BO (Business Object) refers to the business object layer, which is a layer between the DAO layer and the Presentation layer in the application. The BO layer is mainly responsible for processing business logic, coordinating the interaction between various components and data interaction with the Presentation layer.

The BO layer usually includes the following aspects:

1. Business logic processing: The BO layer is responsible for implementing business rules and processes, such as data verification, calculation, conversion and other operations. These business logics may involve the operations of multiple underlying data sources, which need to be implemented by calling the DAO interface.
2. Transaction control: The BO layer can also provide transaction control functions to ensure the atomicity and consistency of business operations. The BO layer can combine the underlying DAO operations into a complete transaction, and perform rollback operations when necessary.
3. Object mapping: The BO layer is responsible for mapping the data model of the underlying data storage with the view model of the upper Presentation layer. This means that the BO layer needs to handle operations such as object conversion, persistence, and serialization.
4. Coordinating various components: As the middle layer of the application, the BO layer needs to coordinate the interaction between various components such as the Presentation layer, DAO layer, and third-party service components. The BO layer can handle the communication between these components, thereby reducing the coupling between the Presentation layer and the DAO layer.

In practice, the BO layer is usually composed of some methods with complex business logic. These methods may operate on multiple database tables and require certain object mapping and conversion. The BO layer can separate the Presentation layer from the DAO layer, making the application easier to maintain and expand.

DTO Data Transfer Object data transfer object

DTO (Data Transfer Object) is a data transfer object used to transfer data between layers. DTO usually contains multiple attributes, which are associated with some business logic and may come from multiple data sources.

DTO mainly has the following functions:

1. Data transfer: DTO objects are used to transfer data between Presentation layer and BO layer, BO layer and DAO layer. DTO objects can convert the data model of the underlying data storage into the view model required by the upper-level business logic, thereby realizing data transmission and interaction.
2. Reduced network load: DTO objects can reduce network load because they contain only the minimum necessary property information. This makes the data transfer process much more efficient, especially in distributed systems.
3. Hiding the underlying data structure: DTO objects can hide the details of the underlying data structure, thereby improving the maintainability and scalability of the code. DTO objects can encapsulate the underlying data structure, so that upper-level components do not need to care about the specific implementation details of the data structure.
4. Serializable: DTO objects can be serialized and deserialized for data transfer between different processes or machines. This enables cross-platform data transfer using DTO objects.

In practice, DTO objects are usually written manually by developers, and the types and properties of these objects should be closely related to business logic. DTO objects should be as simple as possible and only contain necessary attribute information to avoid data redundancy and excessive network load. At the same time, when designing DTO objects, developers also need to consider the reusability and scalability of objects to meet changing business needs.

POJO: (Plain Old Java Objects), simple Java objects

POJO (Plain Old Java Objects) refers to simple Java objects, which are ordinary Java objects without any restrictions and do not depend on a specific framework or interface. POJO objects generally do not contain any proprietary base classes or interfaces, nor are they required to follow any pre-defined rules or contracts.

POJO objects mainly have the following characteristics:

1. Simplicity: POJO objects are very simple, usually containing only data attributes and access methods.
2. Reusability: Since POJO objects have no specific dependencies and specifications, they can be easily reused in different applications.
3. Testability: POJO objects are not tied to any particular framework or interface, so they can be easily unit tested and integrated tested.
4. Extensibility: Since POJO objects do not have any predetermined rules or contracts, they can be flexibly expanded and modified according to business needs.

POJO objects are very common in Java development, and they are widely used in various fields, such as enterprise applications, web development, mobile applications, etc. By using POJO objects, developers can make the code simpler, reusable, testable, and extensible, thereby improving development efficiency and code quality.