Some misunderstandings in the development of Java software

More and more people are starting to use Java, but most of them are not prepared enough (without the training of OO ideology) to be able to navigate the Java project and even slow down the development of the Java system and even become a regular machine. Many people think this is the complexity of Java caused, in fact, the root cause is: We have mastered the software knowledge (oo aspect) is not too poor is inappropriate, there are cognitive and methodological errors.

The Life of software

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

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

At present, a lot of people on the idea of software or focus on the latter: the complete function, feel that a software function more complete the better, in fact, the key is the flexibility of the architecture, the former, the infrastructure is good, the function is only time and workload problems, but if the structure is not good, the function is complete, it is impossible to include all Software is life, in the future growth, more functions need to join, but because the infrastructure is not flexible can not easily join, dead end.

Just because ordinary people to the software there are short-sighted misunderstanding, the function of the pursuit of higher than the infrastructure, a lot of old programmers eat the loss of the software industry, take away the valuable experience of failure, the new blind young programmers or use old thinking forward. In fact, many foreign free open-source frameworks such as OFBiz compiere and slide also exist in this trap, seemingly very in line with appetite, in fact, similar to the domestic those hundreds of yuan of pirated software, scalability and serious lack of sustainable development.

So choose now some of the popular frameworks like Hibernate, Spring/jdonframework, do you mean the infrastructure is ready? 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, the use of stored procedures for the misunderstanding, the use of stored procedure architecture people think can solve performance problems, in fact, it is the cause of performance problems, one of the main culprit, to play a metaphor: if a person dying, a needle can be extended for six months, but hit the needle, all other medical programs are all ineffective, Would you use this short-sighted plan?

Why do you say that? If the stored procedure encapsulates the business process, then the running load is concentrated on the database side, what do you want to do with the middle Java application Server? What do I do to the distributed computing and clustering capabilities of intermediate servers? Only back to the past centralized database host ERA. Software is now facing the Internet, not as confined to a small local area network as in the past, multi-user concurrent access is not determined and measured, relying on a database host is obviously not able to withstand such a poor user access environment. (Of course, the database cluster is only a 50-step and hundred-step difference).

From a hierarchical point of view, now three-tier architecture: The presentation layer, the business layer and the persistence layer, three levels should be divided clearly, the responsibility is clear: persistent layer of responsibility persist to save the business model object, the business layer of the call to the persistent layer is only to help us to activate the object that was entrusted to it, so, cannot because the persistence We are programming around it as a core, and require it to do complex business combinations in addition to returning model objects. A metaphor: You at the railway station will fruit and plate two objects entrusted to the custody of the store, after two days to fetch, you also asked the storage of fruit peeled into pieces, placed on the plate, made of fruit plate to you, reasonable?

Above is a phenomenon of excessive dependence on the persistence layer, there is an exact opposite phenomenon, the persistence layer emitted out, began to squeeze the business layer, corrosion business layer, the entire business layer is seen everywhere is the data table shadow (including the Data table field), rather than the business object. So programmers should look more at OO classic POEAA. POEAA that the data table or table field names should not be seen elsewhere except for persistent layers.

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

Hibernate and other ORM problems

There are a lot of people using hibernate now, but they find hibernate slow, so looking for a solution is not as slow as hibernate, it's the way we use the error:

Hibernate is a technology based on object model persistence, so the key is that we need to design a high-quality object model, follow the DDD domain modeling principles, reduce the correlation, and deal with the association through effective methods such as layering. If you take the design around the data table programming, coupled with a complex relationship between tables (no scientific methods to deal with, reconnaissance or reduce these relationships), it will inevitably lead to slow system operation, in fact, the same problem applies to the original EJB entity Bean CMP Complaints, the entity bean is the domain model persistence, If you do not design the domain Model first, but design the data table, and the persistence tool design goals run counter to, can not problem? About this question N has argued in Jdon for years.

This also extends to another issue: database design issues, do databases need to be designed at project start?

If we are designing a database, we have a series of problems: when we use hibernate for persistence, we have to consider the pre-designed database table structure and how their relationship is mapped to the business object, which is actually very difficult to implement. This is why many people feel that using the ORM framework is a tricky root cause.

Of course, there is also a well-developed brain can be achieved, but the results of this mapping around the database must distort the business object, which is similar to the two plates (data tables and business objects) collided, will inevitably produce earthquakes, the result of the earthquake is a lose-lose, the weak side, the business object is the code, the equivalent of the data table Belong to the soft side, the most cause business objects to become data transfer Objects DTOs, DTOs flying, performance and maintenance problems follow.

Domain modeling solves many of these uncoordinated issues, especially the ORM pain-use issue, about orm/hibernate use or the old adage: If you don't have domain modeling methods, then don't use hibernate, for this level of you: Maybe no ORM is a simple way: no Orm:the simplest solution

Spring Layered Contradiction problem

Spring is to challenge the appearance of EJB, its own powerful component customization function is the advantage, 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 implement business functions such as shopping cart, we need to save the shopping to the session, because the business layer does not have convenient session support, we have to save the shopping cart to HttpSession, HttpSession is only available through HttpRequest, and because it is inaccessible to the HttpRequest object in the Spring Business layer container, we can only save the "shopping cart to HttpSession" in the end. This function is implemented in the presentation layer, which obviously belongs to the function of the business layer, which leads to the confusion and poor maintenance of our Java project hierarchy. Violates the original purpose of using spring and layered architecture.

Domain Driven Design ddd

Now back to the point we're talking about, layered architecture is one of the root causes of our use of Java, and domain modeling expert Eric Evans begins by emphasizing layered architecture in his "Domain Model Design" book. The whole DDD theory is actually telling us how to use the Model object OO technology and the layered architecture to design and implement a Java project.

Many of us now know that the Java project is basically three layers: the presentation Layer business layer and the persistence layer, when we are dedicated to discussing how each layer framework chooses, in fact our real project development work has not yet begun, that is, we have selected a framework of a combination (such as struts+spring+ Hibernate or STRUTS+EJB or struts+jdonframework), we are not aware of the need for business-level work, and DDD provides a new level of thought in the business layer, such as the domain layer and service layer, and even subdivided into job layers, competency tiers, Policy layer, and so on. The loose coupling of complex software is achieved by means of hierarchical refinement. DDD provides a way to subdivide the hierarchy.

When we devote our energies to discussion and research at the technical level of architecture, we may forget the basis for choosing these architectural techniques? domain-driven design ddd answers such questions, and DDD tells you that if a framework doesn't help you implement a layered architecture, then abandon it and DDD also points to the idea of choosing a framework so that you will not conform and fall into the fog of complex technical details, losing the fundamental direction of architectural choice.

Now also some people mistakenly think that DDD is a new theory, in fact, DDD and design patterns, is not a new theory, but a summary of actual combat experience, it will be the predecessors of the use of model-oriented method of experience extraction, for the latter to learn, in order to quickly find the fundamental way to harness our software projects.

Now Evans DDD concept is very fire, because it will be the famous POEAA, realized the POEAA operability, this is also the reason that MF strongly respected. Recently (August 8) A foreigner on the blog with Microsoft. NET Architecture and Evans ddd comparison article: Compare Microsoft's three tier Service Application architecture [Microsoft TLSA] and Evans DDD architecture, using Microsoft. NET Pet Shop 4 as an example, explaining the differences between two goals, and shows how Microsoft is better able to support the latter in a case.

Some misunderstandings in the development of Java software