The business logic in Java EE and the explanation of database access decision

There are 2 completely different ways to design Java enterprise Programs, one of which is the adoption of a standard EJB2 implementation approach (approach). I prefer to call this approach a heavyweight implementation, and when you use the heavyweight implementation approach you need to use session beans and message-driven beans (message-driven bean) to implement the business logic. You can also use Daos (data Access object) or entity beans to access business logic

Another option is to use POJOs and lightweight architecture, which I call the Pojo implementation approach. When using the POJOs implementation approach, your business logic is fully implemented by Pojo. You can use the persistence architecture, also called the object/Relational mapping architecture (a.k.a=also know as) such as Hibernate or JDO, to access the database, and then use Spring AOP (level-oriented programming) to provide enterprise services, such as transaction management and security.

EJB3 because of the integration of POJOs and other lightweight concepts, it is not clear that the difference between lightweight and heavy-test ┑. For example, entity beans in Pojo can be run either in the EJB container or outside the EJB container, whereas session beans and message-driven beans in POJOs still have heavyweight behavior because they can only run inside the EJB container. So, obviously, EJB3 is both a heavyweight and a pojo feature. Entity beans in EJB3 are part of the lightweight implementation approach.

In the development process, the first is to choose from a variety of design in the end to use the weight of the implementation approach or the use of POJO implementation approach. Decisions can affect several aspects of the program, including the business logic structure and the data access mechanism. To help choose between the two implementations, look at this typical enterprise application structure diagram, which is shown in Fig. 1, and you must determine in the design process which strategy to use.

Figure 1. A Typical application architecture and the key business logic and database access design decisions.

The program consists of network basic presentation layer, business layer and persistence layer. The network base presentation layer is responsible for HTTP requests and generates HTML for generic browser clients, XML, and other fat-body clients, such as HTML for AJAX base clients. The business layer is called by the presentation layer to implement the program business logic. The persistence layer is used by the business logic layer to access external data sources, such as databases and other programs.

The design of the presentation layer is not discussed in this article, to see the rest of the chart, we need to determine the interface of the business layer structure, which is provided to the presentation layer and other clients. You also need to decide how to access a database that can be accessed by multiple programs. We must also decide how to deal with the concurrency problems of short-term transactional transactions and long-term transactional transactions. These add up to a total of 5 decisions. Each decision is made by the designer, so that each developer is aware of the strategy in order to be able to read the demo (big picture).

These decisions directly determine the characteristics of the program business and presentation layer design. Of course, there are other important decisions to decide. such as business processing (transactions), security issues, caching issues, and how to integrate programs, but these issues are often discussed in other literatures in the five decisions shown in Figure 1, each with a variety of options. Each choice has a corresponding advantage and disadvantage based on the actual problem it is trying to solve. In subsequent chapters, you will find that each decision has a different balance in terms of functionality, ease of use, maintainability, and usability for one or more areas. Although I'm a pojo fan of implementation, I still need to understand its pros and cons to make the best choice for your program. Let's take a look at the outline of each decision and its options.

Decision 1: Organizing business logic

Now, a lot of attention is focused on the pros and cons of a technology, although it's important, but in essence you need to know how to build your business logic. It is very easy to write code without considering how to organize it. For example, adding code for a session bean is better than in domain mode (field model.: An object model of the domain-incorporates both behavior and data.) It is much simpler to judge that the new feature should be added. Theoretically you still need to deliberately design the most appropriate business logic for your software. After all, I believe you've had the painful experience of modifying someone's garbage structure code.

The key decision is whether you should use the object-oriented approach or the process-oriented implementation approach to implement your program. This is not about technology, but your technical decisions can potentially constrain the organizational structure of your business logic. Adopting EJB2 technology is beneficial to process design, however pojos and lightweight architecture can enable you to choose the best way to implement for special programs.

Adopting process-type design

While I'm an advocate for object-oriented implementations (referring to the use of Pojo and lightframework), there are situations where object-oriented implementations are overqualified, such as you just want to implement a very simple business logic. And, sometimes, object-oriented implementations are not quite feasible-― for example, you don't have a persistence layer to map your objects to a database, and in this case, the better approach is to write process-oriented code, and Martin Fowler is called a transaction script (Transaction) Design pattern is better than adopting an object-oriented approach to design, because you only need to write a method to invoke the transaction processing script to handle the request of the presentation layer.

A very important feature of this approach to seed harvesting is that classes and data stores that are used to implement a behavior are separate. In EJB2 applications, the business logic of this approach is very similar to the design in Figure 2. The core of this design is focused on EJB or pojo behavior because they implement transactional scripts and manipulate "dumb" object data (because they have very little behavior, mostly data). Because most of the behavior is concentrated on a small number of large classes, the code becomes difficult to understand and maintain.

Figure 2. The structure of a procedural design:large transaction script classes and many small data objects

This design has high process-oriented characteristics and does not depend on the characteristics of object-oriented languages. If you have ever used a C or other object-oriented language, you should have used this design pattern. If this pattern works well for your design, it's a good choice to design with this pattern.

This intuitive process development approach is very tempting, because you just need to write code, not to consider how to organize your class files. But the problem is that if your business logic is very complex, your code will become a nightmare to maintain. So unless you're writing a program that's very simple, you should design your program with object-oriented programming instead of being tempted by process-oriented code.