Several misunderstandings in current Java software development

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. Would 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 is the application server in the middle of Java? What do you want to do with the intermediate server's distributed computing and clustering capabilities? Can only go back to the past centralized database host 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 the fruit and plate two objects entrusted to the custody of the custody, after two days to pick up, you also require the preservation of the fruit peeled cut 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. So programmers should look at OO classic POEAA more. POEAA that in addition to the persistence layer, you should not see the data table or table field names 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.