Several misunderstandings in the current Java software development __java

More and more people are starting to use Java, but most of them are not prepared enough (not to be trained on OO ideology) to manage Java projects Well, or even slow down the development of Java systems. Many people think that this is a Java complex cause, in fact, the fundamental reason is: our original knowledge of software (OO) is not too poor or inappropriate, there are cognitive and methodological misunderstanding.

The life of the software

Software is alive, it may be old fashioned, but because it's a matter of layered architecture, it's not too much to emphasize.

A living software must first have a flexible and scalable infrastructure, followed by complete functionality.

At present, many people's thinking about software is still focused on the latter: complete function, feel that a software function more complete the better, in fact, the key or architecture flexibility, is the former, the infrastructure is good, the function is added only time and workload problems, but if the structure is not good, functional and complete, it is impossible to include all future functions, Software is a life, in the future growth, more multi-functional need to join, but because the infrastructure is not flexible can not easily join, dead.

Just because of the common people's short-sighted misunderstanding of the software, the pursuit of the function is higher than the basic structure, many of the old programmers have lost the software industry, take away the valuable experience of failure, new blind young programmers or use old thinking forward. In fact, many foreign free open source framework such as OFBiz Compiere and slide also exist in this aspect of the trap, seemingly very satisfied with the appetite, in fact, similar to the domestic hundreds of of dollars of pirated software, scalability and sustained development of serious deficiencies.

Then choose now some popular framework such as Hibernate, spring/jdonframework whether it means that the infrastructure has been hit well. Not really, the key depends on how you use these frameworks to build your business system.

Traps for stored procedures and complex SQL statements

First of all, talk about the use of stored procedures in the misunderstanding, people who use the stored procedure architecture think they can solve performance problems, which is one of the main culprits of performance problems, metaphorically: If a person is dying, a shot can be extended for half a year, but with this shot, all other medical programs will fail. Will you use this short-sighted approach?

Why do you say that? If the stored procedure encapsulates the business process, then the running load is concentrated on the database side, what to do in the middle Java application Server. What to do with the intermediate server's distributed computing and clustering capabilities. Can only go back to the past centralized database mainframe era. Now the software is oriented to the Internet, not as in the past as limited to a small local area network, multi-user concurrent traffic is unable to determine and measure, relying on a database host is obviously not able to withstand such a bad user access environment. (Of course, the database cluster is only 50 steps and hundred steps of the difference).

From a tiered perspective, the three-tier architecture now: The presentation layer, the business layer and the persistence layer, three levels should be divided clearly, clear responsibilities: persistence layer responsibility persistence to save the business model object, the business layer to the persistence layer of the call only to help us activate the object we have entrusted to keep, so, not because the persistence layer is the custodian, We use it as the core to program around it, in addition to asking it to return the model object, but also requires it to do a complex business mix. Analogy: You at the railway station will be fruit and plate two objects entrusted to the custody of the custody, after two days to pick up, you also require the safe to peel the fruit into pieces, put on the plate, made fruit plate to you, reasonable.

It's a phenomenon that relies too much on the persistence layer, and there's a reverse phenomenon where the persistence layer emits, starts crowding out the business layer, corrodes the business layer, and the entire business layer sees the shadow of the datasheet (including the fields of the datasheet), not the business object. This way programmers should take a look at Oo classic POEAA.POEAA that in addition to the persistence layer, you should not see the Datasheet or table field name anywhere else.

Of course, use of stored procedures, the advantages of using the database is also allowed. According to the Evans DDD theory, SQL statements and stored procedures can be specification as part of the rules.

Hibernate and other ORM problems

There are also a lot of people using hibernate, but they find that hibernate performance is slow, so looking for solutions is not hibernate slow performance, but we use the way error:

"Recently I was engaged in a project, the project we used to Struts1.2+hibernate3, because of the relationship between the complex table and the relationship between the table many, in many places the lazy are set to false, so that the data load is very slow, and query a data is very slow." ”

Hibernate is a technology based on object model persistence, therefore, the key is that we need to design a high quality object model, follow the DDD domain modeling principle, reduce the reduction of association, and deal with the association through effective methods such as layering. If you take design programming around a datasheet and the complexity of the tables (there is no scientific way to handle, scout, or reduce these relationships), the system will inevitably slow down, but the same problem applies to CMP complaints from the original EJB entity bean, which is domain model persistence, If you do not design domain Model first, but design the data table, and the persistence tool design goals run counter, can not be a problem. About this problem n years in Jdon dispute.

This also extends to another problem: database design issues, whether the database needs to be designed at the beginning of the project.

If we do database design, we have a series of problems: when we use hibernate to implement a persistent save, we must consider the database table structure in advance and how their relationship and business object implementation mapping, which is actually very difficult to achieve, This is also why many people feel that using an ORM framework is a tricky root cause.

Of course, there are people with a lot of brainpower that can be achieved, but the result of this mapping around the database must distort the business object, which is similar to two plates (data tables and business objects) collided, must produce earthquakes, the result of the earthquake is mutually-loss, soft side disadvantage, business object is code, the equivalent of the data table structure, Belong to the soft side, resulting in the business object into a data transfer object DTO, DTO flying, performance and maintenance problems.

Domain modeling solves many of these uncoordinated problems, especially ORM pain usage, about orm/hibernate use or the old saying: if you don't know the domain modeling method, then do not use hibernate, for this level of you: Perhaps no ORM is a simple way: no Orm:the simplest solution

Spring Layered conflict issues

Spring is a challenge to the EJB appearance, its own powerful component customization features are the advantages, but there are some practical problems, spring as a business layer framework, does not support the business Layer session function.

Specific examples are as follows: When we realize the shopping cart and other business functions, we need to save the shopping situation to the session, because the business layer has no convenient session support, we have to save the cart to HttpSession, And httpsession can only be obtained through HttpRequest, and because the HttpRequest object cannot be accessed in the Spring Business layer container, the last thing we can do is save the "cart to HttpSession" This feature is implemented in the presentation layer, which clearly belongs to the business layer function, which causes our Java projects to be cluttered and poorly maintained. Violates the original purpose of using spring and layered schemas.

Domain Driven Design ddd

Now back to the point of our discussion, layered architecture is one of the root causes of our use of Java, and the domain modeling expert Eric Evans begins with the first emphasis on the layered architecture in his book "Domain Model design." The whole DDD theory actually tells us how to design and implement a Java project using model object OO technology and layered architecture.

Many of us now know that Java projects have basically three layers: the presentation Layer business layer and the persistence layer, and when we are committed to discussing how each layer framework is chosen, actually our real project development work has not yet begun, that is, we have chosen a combination of some frameworks (e.g. struts+spring+ Hibernate or STRUTS+EJB or struts+jdonframework), we are not aware that the business layer work still requires a lot of work, DDD provides a new level of thinking in the business layer, such as the domain layer and service layer, and even subdivided into the operating layer, capacity level, Policy layer, and so on. The loose coupling of complex software is achieved by the way of hierarchy refinement. DDD provides a way to subdivide the hierarchy

When we spend our energy on architectural technical discussions and research, we may forget the basis for choosing these architectural techniques. What is the selection criteria. Domain-driven Design ddd answered the question, DDD will tell you that if a framework does not assist you in implementing a layered architecture, then abandon it, and DDD also points to the consideration of the choice framework so that you will not be able to conform to the complexity of the technical details of the fog, lost in the fundamental direction of architectural choice.

Now some people mistakenly think that DDD is a new theory, in fact, DDD and design pattern, is not a new theory, but a summary of actual combat experience, it will be used by the predecessors of the model design method of experience to extract, for the successor to learn, in order to quickly find the master of our software projects the fundamental way.

Now Evans DDD concept is very hot, because it will be the famous POEAA, realize the POEAA operability, this is the reason that MF strongly praised. Recently (August 8) A foreigner blog on the use of Microsoft. NET Architecture and Evans ddd comparison: Compare Microsoft's three-tier service Application architecture [Microsoft Tlsa] and Evans DDD architecture, using Microsoft. NET Pet Shop 4 As an example to explain the difference between two goals, And show how Microsoft is better able to support the latter in the case. What this article helps. NET platform for people with domain design knowledge to achieve better improvement.

The other one about. NET DDD books have also been published, which indicate that Evans DDD has burned the fire. NET domain, of course, DDD in the Java field rooting for many years, Evans's DDD books is in Java as an example, the author Banqiao also pioneered in 2005, the DDD Framework Jdonframework 1.3 version, these are explained, Java is always one step ahead in the practice of advanced thinking in the whole software industry.