Currently, various technologies in the Java field are blooming, with a wide range of names. How can we choose these frameworks based on our own needs? Especially for beginners, they are also very confused about the direction of learning. It is even more important to learn based on the characteristics of their projects.
Next we will consider the birth of these J2EE/Java EE frameworks from a development perspective, which may be of great help to our selection.
First, we need to understand what a high-quality J2EE system looks like? High-quality J2EE/Java EE system standards are actually OO design standards. Loose coupling is one of the main objectives of OO design. Therefore, decoupling is undoubtedly the primary standard for measuring the quality of J2EE/Jee. In actual selection, you also need to consider both scalability, performance, and development efficiency.
J2EE/Java EE is known as a multi-layer structure. Why is the multi-layer architecture better than the two-layer architecture? Due to the good decoupling of multi-layer structures, maintenance expansion is convenient and flexible.
A typical J2EE/Java EE consists of at least three layers: presentation layer, business logic component layer, and persistence layer.
In English, the presentation layer is the presentation layer, which implements the display function. This part is generally completed using the B/S structure. Of course, you can also use a dedicated remote client;
The business logic layer is composed of a large number of components, also known as the component layer. components can be divided into various types from different perspectives, and then have different genres, currently, model + service and model plus service are the main locations. Therefore, this layer is also called the business service layer, or the model business layer;
The persistence layer is the layer responsible for Object persistence, that is, database operations.
Sun partners introduced the J2EE standard, which sets the standard implementation for these three layers, the presentation layer uses JSP/Servlet technology, the Business Component layer uses the EJB session bean, and the persistence layer uses the Entity Bean. At the same time, the standard physically combines the business layer and the persistent layer into a new container EJB container, which is exactly the same as the presentation layer technology. In this way, the J2EE technology is refined into web and EJB, there are Web containers and Web applications physically, as well as EJB containers and EJB applications.
Of course, the development of J2EE/jee is not limited to this. The three layers of technology develop independently and are advanced. The following separately States why a framework technology came into being, you may know under what circumstances you should choose them. Tools are always born for purpose!
Presentation layer framework
Although J2EE/Java EE is a multi-layer structure, it is not a mandatory multi-layer structure. That is to say, you may also make it a traditional two-layer structure, some beginners directly use JSP to embed Java code to call the database. This structure is not a multi-layer structure, or the previous two-layer structure.
A large amount of code is embedded in JSP. Once a null pointer error is reported, it is difficult to find a problem. Many beginners often encounter this problem after downloading jivejdon 2.5. Therefore, a large number of NULL pointer errors occur in the Forum, why can't they solve it by themselves? This is because the location of the error in JSP cannot be located. Tomcat and other servers only tell us the location of the error in index_jsp.java (JSP Java file, some people often go to the Tomcat server to find JSP java files. This process is extremely painful (to reduce the pain of beginners, the download of jivejdon2.5 is suspended on this site ).
The development of J2EE/Java EE is to reduce this pain. The first way to think of it is to work hard in JSP debugging and require Tomcat and other servers to provide detailed error locating; unfortunately, we didn't see this feature in Tomcat 5.5. In fact, the fundamental solution is to turn JSP debugging into Debugging for Java components.
First, through the MVC pattern, jsp can only be equivalent to HTML and cannot contain Java code. jsp and Java code are separated. However, after such separation, it is troublesome to combine them, although you use the MVC mode, you still directly rely on JSP technology to reduce development efficiency.
The Struts framework solves this problem. Through actionform, JSP and JavaBeans can be easily and quickly combined. However, some people complain that the struts actionform is too restrictive, only one actionform can correspond to one form, but not any component JavaBeans can correspond to any JSP field. In this case, the component framework JSF/tapestry is created.
Performance layer framework struts/tapestry/JSF architecture comparison
Business logic layer framework
Scalability
Since the launch of the EJB standard, the Business Component layer was basically the world of EJB, but the EJB function was so powerful that it took into account the needs of the world's top-level large systems, so it inevitably Seemed complicated, basically, all large enterprises use J2EE for the high-end, and select EJB for the J2EE. The high scalability emphasized by ejbs provides the largest space for the development of large enterprises. The rapid development of enterprises no longer leads to fundamental changes in the entire enterprise system structure. This is the practical advantage of using ejbs.
The scalability of such enterprise systems is not important because of the existence of ejbs, but is the basic factor for us to consider when choosing an enterprise architecture. In other words, whether we use EJB or not, we need to consider the following: What should we do if one server is not enough? If this server crashes, what will the impact on enterprise operations? If this server is shut down and maintained and upgraded every week, will it bring a blow to the Enterprise? Does my enterprise system need a reliable, almost improper 7x24 server? Is one server sufficient when the enterprise system faces a large number of external access users? Does the need for linkage between multiple servers involve software technical replacement?
After considering this practical factor, if you think it is not very important, or it doesn't matter for some time in the future, you can choose not to use EJB.
Why is there a reason not to use EJB? Because of its complexity and difficulty in learning, EJB helps us to consider most of the problems that may occur in the enterprise. In fact, some of them are not required, that is why EJB is a heavyweight solution.
Compared with the heavyweight model, the lightweight solution of the Business Component layer includes spring, hivemidn, and jdon framework. The word lightweight has become fashionable because of the emergence of EJB, this is a misunderstanding of the features that EJB uses to accomplish. Using my lightweight solution can be easily solved.
When spring, which was once simple and self-built, incorporated the transaction mechanism into its own arms, it began to be low-key and lightweight, but it was actually not light or heavy; of course, if it added distributed computing and transactions again, the balance will also sink.
Beginners are always willing to use simple solutions and learn and use them conveniently. Therefore, they prefer lightweight frameworks. This is normal, but they must understand before using lightweight frameworks: will your system really only need one server in the future? Is your project's completion really urgent?
If you only need a super-strong server, you do not need to select ejbs. ejbs are generated by multiple distributed servers. For a single server, there is a lack of local transparency, that is: you cannot directly deal with local JVM or file systems through ejbs. Transparency is also an important indicator of a framework.
Of course, the weight and lightweight components are not totally different. ejb3 aims to simplify the use of J2EE, so that EJB is not only good at processing large enterprise systems, but also convenient for small and medium systems, this is actually an effort of lightweight EJB. What is Java ee 5?
Therefore, for architecture selection, the fundamental premise is to understand whether your system is a small or medium-sized system or a large system for a period of time now or in the future (consider the future, not just looking at it?
Flexibility/customization/transparency
Of course, this answer is sometimes difficult for us to give, so we still need to consider the choice of EJB and non-EJB from other perspectives. For example, I have experienced a Community system on a large real-time entertainment platform, in terms of scale, it must be a large system with a design goal of 0.1 million online users. From this perspective, it is not necessary to select ejbs!
However, because there is a transaction mechanism in EJB, although the application can choose to invalidate EJB transactions, the EJB container design always seems bloated in its kernel because of the consideration of transactions, it is a type of cumbersome, which is also a type of weight representation. The existence of unwanted things will definitely affect the efficiency. Isn't it possible for me to meet my needs, can I perform configuration-based cutting on EJB containers? That is to say, in the above case, only the distributed computing function of EJB is required, and other functions are removed. Only the functions that I need can be run, so I can install them lightly.
Unfortunately, this kind of arbitrary cutting has not yet been taken seriously by the ejb3 standard. Fortunately, IOC/AOP technology provides implementation possibilities for this kind of goal. However, IOC/AOP alone is not enough, especially the scope of IOC. If you only include application system components in IOC management, free decoupling only belongs to the application system, my goals in the above case are still not met. When you manage the components of the framework itself in IOC, you can achieve the desired goals if you want to cut them at will.
Spring and ejb3 belong to "only integrate application system components into IOC Management", which can be seen from JBoss 4.0. Which framework will also incorporate the framework components into IOC management? Hivemind of Apache and jdon framework developed by the author.
What components can be included in IOC management? The concept of pojo component and pojo was introduced to address the disadvantages of EJB. EJB requires that the components of the application system must inherit or depend on the EJB container, which makes debugging inconvenient, the concept of pojo is not just the original concept. pojo represents the object that is completely independent from the surrounding and free. If the model or service of the application system is pojo, this means that your application system does not depend on any other system, and the decoupling flexibility is high.
Pojo was proposed because of ejbs. When EJB tends to be pojo, when everyone declares that he is a pojo, the concept of pojo has no foothold. This is also a strange phenomenon in the Java field, however, I personally prefer to call non-EJB JavaBeans components pojo.
The IOC dependency injection function of hivemind is similar to that of the jdon framework. When hundreds of pojo components are configured, you do not need to specify the dependency between them; you can register your application components in the registry, so hivemind will help you start these components, just as you write your components into mycontainer in the jdon framework. in XML, the jdon framework also automatically starts your components and solves the mutual calls between them, including interacting with the components of the framework itself.
The pojo service defined by hivemind and jdon frameworks has the following features:
Unlike EJB, which lacks the concept of local transparency, these pojo services can always be located in the same JVM, and language transparency is not the same as XML-based Web Services) concept, these pojo services can always be generalized and replaced by a set of Java interfaces (by calling a Java interface to call these specific services); of course, it is not similar to JMX or Jini, hot-loading is not supported ).
Note: When IOC/AOP is highly flexible, and some beginners have begun to complain about the excessive flexibility of spring, the jdon framework that is more flexible than spring in terms of components can only be regarded as an extreme pursuit, it does not necessarily constitute the main basis for your architecture selection!
The above discussions only show that your application system needs to have different requirements on the demand of flexibility (decoupling/transparency, some requirements are even extreme. This degree of bias becomes the goal of your architecture selection. If your extreme requirements are not available in the Java World, then you have to do it yourself. This also shows when you start to do the framework yourself (such as the jdon framework), although in most cases we do not have to invent the wheel ourselves.
Quick build
We discussed the architecture selection goal from the perspective of flexibility and customization. However, in general, we still choose the architecture from the perspective of ease of use and development efficiency. From this perspective, we need to use the framework as much as possible to help us implement some functions, but this is in conflict with the ease of use. Therefore, there is a trade-off problem and there is a trade-off principle: this framework provides as many functions as possible. We need to write less code or even less code (using xml configuration), so we can use less brains.
Xml configuration also involves difficulties. The xml configuration syntax cannot be too complex. Too many small switches also increase learning costs.
From this perspective, ejb2 or ejb3 provides the most complete functions, but there are too many xml configuration switches. Spring is medium, and the xml configuration of components is not simple, however, because there are a lot of ready-made open source code such as Struts + spring + hibernate for reference, it is not difficult to learn. Spring is more and more like a J2EE API (note that JDK is a j2se API ), in addition to being unable to provide distributed computing, spring also reduces development efficiency due to excessive flexibility. For example, its component dependency needs to be specified gradually, and the auotwiring function has not yet become a core function. The revolutionary advantage of IOC containers.
In addition to the component layer function, spring also supports spring MVC in the presentation layer and JDBC templates implemented by the persistence layer. In this way, spring provides default implementation at all levels of the J2EE/Java EE system, which undoubtedly improves the development efficiency. However, spring does not seem to provide a wide range of APIS for rapid development, instead, a complete API function library is created. As described in the beginning of a webpage: as the leadingFull-StackJava/J2EE application framework. Note that full-stack (complete) is a prominent term.
There is another blank, that is, taking development efficiency as the main consideration. In addition to sufficient flexibility and rich functions, such frameworks must be considered, the objective is to quickly complete a J2EE/Java EE system by default, which is very similar to the MDA tool, however, we do not welcome an MDA tool that completely loses flexibility and customization.
The development goal of the jdon framework is to fill this gap. I believe more and more frameworks will be moving towards this goal. Of course, it is undeniable that spring may also turn its head into this field, ejb2/ejb3 is moving closer to this field by using such commercial development tools as JBuilder. This development direction is actually 4gl RAD tools.
Many people have also explored the rapid construction and various tools have emerged: How to build a quick business component platform? But how can we combine quick building with component flexibility? It is a criterion for testing the quality of a business component (Business Component) platform. Although some component platforms are developed rapidly, there are not many transparent operations that can be customized by programmers in special cases. A typical example is the previous two-layer structure Delphi, which is very fast in development, however, it is impossible to go deep into all levels of the system for customization, maintenance, and expansion like J2EE!
Business Component Framework comparison
|
Persistence Layer framework
The persistence layer framework currently includes ejb2/ejb3 entity beans, Hibernate and various JDO products. Of course, JDBC for Directly Writing SQL statements, such as ibatis.
The good quality and bad distinction of the persistence layer framework is whether it is o/R Mapping, that is, object and relational database ing. The relational database needs to define the schema structure; the object also has its own structure because of the field. To automatically persist the object data to the database, we must first define the corresponding structure of the two, which is actually the metadata definition of the data.
Because o/R Mapping tools such as hiberante, toplink, and JDO help you implement object and database conversion and overcome object and database impedance phenomena, O/R Mapping summary, therefore, we can consider the Java EE/J2EE system more in the object mode (from the model object). We can completely discard the previous database-centric approach: the end of the database era.
Therefore, whether or not a good persistent layer framework is selected depends on whether your entire team's thinking is completely Oo and whether real OO is required. Of course, for some small projects, sometimes we feel that it is easier and quicker to directly use the JDBC template, which is also the reason why the JDBC template of spring/ibatis/jdon exists.
For example, to add a data table, you only need the following lines of code in the jdon framework:
| String SQL = "insert into testuser (userid, name) values (?, ?) "; List queryparams = new arraylist (); Queryparams. Add (usertest. getuserid ()); Queryparams. Add (usertest. getname ()); Jdbctemp. Operate (queryparams, SQL ); |
This method is faster than O/R mapping, which allows programmers who are familiar with SQL statements to think about multiple XML configurations and relational mappings.
From the above we can see that flexibility, speed, simplicity, and scalability are the main basis for our architecture selection. The architecture selection is actually a balance between these policies. Of course, there is also a very important factor, because it does not belong to a certain level of technology, performance/cache must be taken into account with the above factors.
Because performance was initially the basic reason for using computers, don't forget this.
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
