Summary: MVC layered Architecture

Pojo:plain ordinary Java object Simple, non-regular Java objects, I personally think it and other not a level of things, Vo and Po should belong to it

The Po:persistant object is persisted as a Java object that is mapped to a table in the database. The simplest PO is a record in a table in the corresponding database, and multiple records can be used with a collection of PO. The PO should not contain any operations on the database

Do:domain object domain objects are tangible or intangible business entities that are abstracted from the real world. The table structure in general and data corresponds

Dao:data Access object that is used to access the database. Usually used in conjunction with PO, DAO contains various methods of operation of the database. By means of this method, we combine the PO to carry on the related operation to the database

vo: Value object. Typically used for data transfer between business tiers, as is the case with PO, which contains only data. But it should be abstracted out of the business object that can correspond to the table, or not, depending on the needs of the business. Personal feel with DTO (data transfer object), passing on the web

Bo:business object Business objects, which encapsulate Java objects of business logic, by invoking the DAO method and combining Po,vo for business operations

vo ": View object, for presentation layer, Its purpose is to encapsulate all the data for a given page (or component).
DTO (Data Transfer object): Data Transfer object, this concept originates from the design pattern of the Java EE, the original purpose is to provide the coarse granularity data entity for the distributed application of the EJB, in order to reduce the number of distributed calls, This improves the performance of distributed calls and reduces network load, but here I refer to the data transfer object between the presentation layer and the service layer.
Do (domain object): Domain objects are tangible or intangible business entities that are abstracted from the real world.
PO (Persistent object): A persisted object that forms a one by one mapping relationship to the data structure of the persistence layer (usually the relational database), and if the persistence layer is a relational database, Each field (or several) in a data table corresponds to one (or several) attributes of the PO.

Vo differs from DTOs
       You may have a question (many programmers have the same doubts in the project I'm involved in): Since DTOs are objects that pass data between the presentation layer and the service layer, Why do you need a VO? Right! For most scenarios, dto and VO attribute values are basically consistent, and they are usually pojo, so there is no need to superfluous, but do not forget that this is the implementation level of thinking, for the design level, there should be the concept of VO and DTOs, because the two have an essential difference, A DTO represents the data that the service layer needs to receive and the data returned, and VO represents the data that the presentation layer needs to display.
       Using an example to illustrate it may be easier to understand: for example, the service layer has a GetUser method that returns a system user with a property of gender (gender), For the service layer, it is only semantically defined: 1-male, 2-female, 0-unspecified, and for the presentation layer, it may need to use "handsome" on behalf of men, with "beautiful" for women, with "secret" representative unspecified. Speaking of which, perhaps you will also refute, in the service layer directly back to "handsome" is not OK? This is not a problem for most applications, but imagine that if the requirements allow customers to customize the style, and the different styles do not behave differently for "gender", or if the service is used by multiple clients (different portals), and different clients have differing requirements for the performance layer, then the problem comes. Furthermore, back to the design level, from a single principle of responsibility, the service layer is only responsible for the business, independent of the specific manifestation, therefore, the DTO that it returns should not appear coupled with the form of expression.
       theory, this is the analysis of the design level of thinking, whether the implementation level must do so? One-size-fits-all approach tends to outweigh the gains, and I'll immediately analyze how to make the right choices in the app.

The application of VO and DTO
The above only uses a simple example to illustrate the conceptual difference between VO and dto, and this section will show you how to make the right choice in your application.
In the following scenario, we can consider the VO and the Dto two to one (note: is the implementation level):
When the requirements are very clear and stable, and the client is very clear only one time, there is no need to distinguish between VO and dto, when VO can retire, with a dto can, why Vo retired rather than DTOs? Back to the design level, the responsibility of the service layer should still not be coupled with the presentation layer, so, for the previous example, you can easily understand that DTOs for "gender", still can't use "handsome", this conversion should rely on the page script (such as JavaScript) or other mechanisms (JSTL, EL, CSS)
Even if the client can be customized, or there are many different clients, if the client can use a technology (script or other mechanism) to achieve the conversion, the same can let VO retire

The following scenarios need to prioritize VO and dto coexistence:
The reverse scenario of the above scenario
For some technical reasons, such as when a framework (such as Flex) provides automatic conversion of Pojo to some field in the UI, you can consider defining VO at the implementation level, This tradeoff is entirely dependent on the comparison between the development and maintenance efficiencies brought about by the use of the framework's automatic conversion capability and the increased efficiency of the development and maintainability of the design more than what VO does.
If a page appears with a "large view," and all the data that makes up the large view needs to call multiple services and return multiple DTOs to assemble (of course, this can also be replaced by a dto that returns a large view at the service layer, but it is appropriate to provide a method at the service layer, Needs to be weighed at the design level).

The difference between a dto and do
       first is a conceptual difference, a DTO is a data transfer object between the presentation layer and the service layer (which can be considered an agreement between the two). And do is an abstraction of various business roles in the real world, which leads to differences in data, such as userinfo and user (for DTOs and do naming conventions, see the author's previous blog post), which in essence should never return a user's password for a GetUser method. , so userinfo is at least one password less data than the user. In domain-driven design, as the first series of articles says, do is not a simple pojo, it has domain business logic.

Use of DTOs and do
       from the example in the previous section, the attentive reader may find the problem: Since the userinfo returned by the GetUser method should not contain password, Then there should be no password this attribute definition, but if there is also a CreateUser method, the incoming userinfo need to include the user's password, what to do? At the design level, the DTO that the presentation layer passes to the service layer is conceptually different from the DTOs that the service layer returns to the presentation layer, but at the implementation level, we typically rarely do this (define two userinfo, or more), because it is not necessarily wise to do so, and we can design a fully compatible DTO , when the service layer receives data, the properties that should not be set by the presentation layer (such as the total price of the order should be determined by its unit price, quantity, discount, etc.), regardless of whether the presentation layer is set up, the service layer is ignored, and when the service layer returns data, the data should not be returned (such as user password),
       for do, there is one more thing to note: Why not just return to do in the service layer? This eliminates the ability to encode and convert DTOs, for the following reasons:
The difference between the two is inherently different, and a dto may correspond to multiple do, and vice versa, or even a many-to-many relationship.
Do has some data that should not be known to the presentation
do has a business approach, and if you pass do to the presentation layer, the Code of the presentation layer bypasses the service layer directly calling the operations it should not access, especially for the mechanism of access control based on the AOP interception service layer, The business method of calling do at the presentation layer also makes the transaction difficult to control because of transaction issues.
for some ORM frameworks, such as Hibernate, the "lazy load" technique is often used, and if do is exposed directly to the presentation layer, for the most part, the presentation layer is not within the scope of the transaction (Open session in View is not a well-respected design in most cases, and if it tries to get an associated object that is not loaded when the session is closed, a run-time exception occurs (for Hibernate, lazyinitiliaztionexception).
from the design level, the presentation layer relies on the service layer, the service layer depends on the domain layer, if do exposed, it will lead to the presentation layer directly depends on the domain layer, although still a one-way dependency, but this cross-layer dependency will lead to unnecessary coupling.

For DTOs, it is also important to note that DTOs should be a "flattened two-dimensional object", for example, if the user associates several other entities (such as address, account, region, and so on), then GetUser () Return userinfo, do you want to return the DTO of the object it is associated with? If this is the case, it will inevitably lead to a large increase in data transmission volume, for distributed applications, because of the data on the network transmission, serialization and deserialization, this design is more unacceptable. If GetUser needs to return a accountid, AccountName, RegionID, Regionname, in addition to returning the basic information of the user, define these attributes to userinfo and flatten a "stereo" Object Tree "Into a" flat two-dimensional object ", the author is currently involved in a distributed system, the system regardless of 3,721, all of an object's associated objects are converted to the same structure of the Dto object tree and return, resulting in very slow performance.

The difference between

do and PO
       do and PO is one by one in most cases, PO is a pojo that contains only the Get/set method, But some scenarios still reflect the conceptual difference between the two:
do does not need to be persisted explicitly in some scenarios, such as a commodity discount strategy designed with a policy model, which will derive the interface of the discount policy and the implementation classes of the different discount policies, and these discount policy implementation classes can be considered do, However, they reside only in static memory and do not need to be persisted to the persistence layer, so there is no corresponding PO for this type of do.
Similarly, in some scenarios, PO also does not have a corresponding do, such as teacher teacher and student student there are many-to-many relationships, in a relational database, this relationship needs to be represented as an intermediate table, but also for a teacherandstudentpo Po, But this PO does not have any realistic meaning in the business field, it can not correspond with any do at all. In particular, it is stated here that not all many-to-many relationships have no business meaning, which is related to specific business scenarios, such as: the relationship between the two PO affects the specific business, and there are many types of this relationship, then this many-to-many relationship should also be represented as a do, such as: "Role" and "resources" There are many-to-many relationships, and the relationship is clearly represented as a do--"permission."
In some cases, for some persistence strategy or performance consideration, a PO may correspond to multiple do and vice versa. For example, customer customers have their contact information contacts, here is a two-to-one relationship between do, but may be due to performance considerations (extreme cases, rights as an example), in order to reduce the database connection query operation, Merge the customer and contacts two do data into a single data table. Conversely, if there is one property that is a cover cover, but this property is a picture of binary data, and some query operations do not want to load cover together, thus reducing disk IO overhead, and assuming that the ORM framework does not support attribute-level lazy loading, Then it is necessary to consider cover independent into a data table, so as to form a do to deal with a PO case. Some of the property values of the
Po do not make any sense to do, and these attribute values may be data to resolve some persisted policies, for example, in order to implement an "optimistic lock", the PO has a version of the property, this version for Do has no business meaning, It should not exist in do. Similarly, there may be properties in do that do not need to be persisted.

Application of Do and PO
Since the ORM framework is very powerful and has a large line, and Java EE has introduced the JPA specification, now the business application development, basically do not need to distinguish between do and po,po can be hidden in do by Jpa,hibernate ANNOTATIONS/HBM. Nevertheless, there are some problems that we must pay attention to:
For a property that does not need to be persisted, an ORM explicit declaration is required, such as: In JPA, you can take advantage of the @transient declaration.
For properties that exist in the PO for some persistence policy, such as version, because do, PO are merged, must be declared in do, but because this property has no business meaning to do, it is necessary to hide the property from the outside, the most common practice is to privatize the property's Get/set method, Does not even provide the Get/set method, but for hibernate, this requires special attention, because hibernate from the database read data to do, is to use the reflection mechanism to call do the empty argument constructor to construct a do instance, Then using the JavaBean specification to reflect the set method to set a value for each property, if you do not explicitly declare the set method, or set method to private, will cause hibernate to fail to initialize do, resulting in a run-time exception, It is advisable to set the property's set method to protected.
Hibernate provides good support for a do-to-multiple PO, or a PO for multiple do scenarios, and attribute-level lazy loading, as well as hibnate.

In simple terms:

In code VO (value object) DTOs do are the corresponding entities that can be considered as entity before

Bo is the operation of the single table service is the operation of multi-table service can call Bo (including Bo)

Domain equals controller

Domain exposes users to make calls

---restore content ends-----------------------Ethereal translationData Source:

Summary: MVC layered Architecture