Thinking of enterprise-level development

In the past, I have always believed that enterprise-level development is sacred and cannot be questioned. Although sometimes they also recognize the " how big butt wear underwear , " the truth, but that heavyweight development model in their own mind occupies the position has been inviolable. It was not until recently that the company decided to do something that the enterprise level was really heavy, and that it was less than 90%.

Before considering EJB and spring, I have always thought that only ejbs are biological, and spring is just a very strong weed. But the problems I have encountered in my recent work have changed my previous views.

In a pure EJB system there is no doubt that JPA is used to persist, but due to the need for system upgrade we have to change the database, plus field batch update and so on are very common, initially intended to use JDBC directly before the system to perform SQL completion of the upgrade, But because Entitymanager has its own set of management system, so it will lead to deadlock, and this deadlock problem is at the database level, it is more frightening to use JDBC to think that the entitymanager of the transaction, then upgrade this operation can only succeed can not fail, Otherwise, the system will not get up after the transaction is rolled back. After weighing the pros and cons and deciding to use JPA to execute native SQL directly, the experience in this process is extremely uncomfortable. It's like holding a AK47 to be a hammer, can you knock a nail? Can you kill the enemy? Yes, but the right way to use it is to load the bullets and shoot them. This means that the current usage is not defined at the beginning of this tool design. JPA is used to persist, directly running the native SQL although it can but this is not its advantage, so how to use how lame.

Recently, the company intends to enter the peer-to, the customer is the next task is to quickly develop a prototype, at the very least to allow customers to understand the interface and features. So the question is, what about technology selection? What is the EJB's set? Want customers to wait one or two months? It was estimated that the client had already run away. Eventually the company decided to use spring's stuff to get the prototype out, and then to weigh the EJB or spring based on the scale the client was going to take. EJB can be distributed, although it can be used to solve the problem of performance of the cluster, but in terms of speed it is not as good as spring, it is not called Heavyweight.

Is there not a thing that can be quickly and easily expanded into a heavyweight? It would be nice to have a feeling like " Santo " .

Thinking of enterprise-level development