The most important Java EE best practices

Introduction

Over the last decade or so, people have written a lot about Java™platform, Enterprise Edition (Java EE) best practices. There are now more than 10 books and hundreds (perhaps more) of articles that provide insights into how Java EE applications should be written. In fact, there are so many references in this area, and there are often conflicting suggestions among these resources that learning in these mixed content is an obstacle to using Java EE. Therefore, in order to provide some simple guidance to customers who have just entered this field, we have compiled this most important list of best practices, including the most important and effective Java EE best practices. Unfortunately, we cannot describe all the content that needs to be covered in just 10 best practices. Therefore, in order to avoid missing out on key best practices and respect for Java EE Development, our list includes the "19" key Java EE best practices.

1. Always use the MVC framework.

Separates business logic (Java beans and EJB components) from controller logic (Servlet/struts operations) and presentation logic (JSP, XML/XSLT). Good tiering can bring a lot of benefits.

This practice is so important that no other best practice can be compared with it. Model-View-Controller (MVC) is critical for good Java EE application design. It simply divides the tasks of the program into the following sections:

Part of the business logic (model, usually implemented using Enterprise javabeans™ or traditional Java objects).

The portion (view) that is responsible for the user interface representation.

The part (Controller) that is responsible for the navigation of the application, usually implemented using classes related to the Java Servlet or the class Struts controller.

For Java EE, there are a lot of good reviews on this topic, and we specifically recommend that interested readers refer to [Fowler] or [Brown] (see the Resources section) for a comprehensive and in-depth understanding of the relevant content.

If you do not follow the basic MVC architecture, there will be many problems in the development process. The most common problem is to put too many tasks in the View section of the architecture. There may be a use of JSP tags to perform database access, or process control of an application in a JSP, which is more common in small applications, but with later development this can be problematic because JSP is becoming increasingly difficult to maintain and debug.

Similarly, we often see situations where the view layer is built into business logic. A common problem, for example, is to apply XML parsing techniques used in building views directly to the business tier. The business layer should operate on business objects rather than on specific data representations related to views.

However, using the appropriate components alone does not enable the application to be properly layered. We often see applications that contain all three of the servlet, JSP, and EJB components, however, the main business logic is implemented at the servlet level, or the application navigation is handled in the JSP. You must rigorously examine and refactor your code to ensure that only the business logic is handled in the model layer, application navigation is done in the controller layer, and the view should only care about rendering the model objects as appropriate for HTML and Javascript™.

The implications of this proposal in this article should be clearer than in the original version. User interface technology is constantly changing, associating business logic with the user interface, and making changes to the interface affect existing systems. A few years ago, WEB application user interface developers might choose from Servlet and JSP, Struts, and xml/xsl transformations. After that, Tiles and Faces were very popular, and now AJAX is a great way to do it. It would be awful if the core business logic of the application was to be restarted whenever the preferred user interface technology changed.