The rigidity of thinking in software development

In the field of Java EE, Ssh/ssi is a good thing, the master's painstaking crystallization. But he was a bad man, too.

On the good side, I believe needless to say, a lot of design patterns to use, greatly reducing the entry threshold of programmers, standardize enterprise application development, improve production efficiency and so on. Whether from the cost of the enterprise or the development of personal technology, is the essence of the work.

What's the downside of What:ssh/ssi?

Now, let's talk about its bad side:

1. Lower the programmer entry threshold

You only need a "xx days to learn XX", you can participate in the work, to win the envy of other industries pay. But, is this really good?! We do not talk about the program is the combination of algorithms and data structure, not the theory and technology on the tall, we are ordinary people. It's good to be able to quickly learn a technology from the point of need of employment. However, when a lot of ordinary people tasted the sweetness of quick success, I feel that technology is so, when I used to hold the Buddha's feet temporarily, so do not think enterprising, mixed eating and so on death. More and more enterprise application developers are entering this state. Some people know that this is wrong, but see others are like this, they go with the crowd, do not change.

2. Standardize enterprise application development

From the perspective of enterprise production, can not be standardized things, the formation of standardized process of the production process, which is very good thing, can greatly reduce production costs, improve product quality. But the byproduct of the process is rigidity!

As mentioned earlier, because the entry threshold lowered, mixed-up, the level of personnel uneven. For such norms, some people understand that he is the norm, is a reference, some people understand that he is a rule, is a must abide by the criteria, coupled with the idea of not enterprising, know it but do not know why, leading to such a rigid phenomenon more serious.

3. A large number of design patterns used

Some developers see the framework so use design patterns, so see what is like nails, this is not related to this topic, there is not much discussion.

Why: It's his bad.

Let's take a look at concrete examples.

Believe that many people in the development of SSH/SSI applications, will write Jsp,action,service,dao these several typical modules. So why should I develop a feature that requires writing these modules, and why can't I do it in other ways?

Some say that because it follows the MVC pattern, it is a tiered model for business, easier to develop and maintain, and communicate with other developers.

So, let's start with MVC and see why we're doing this.

The V:view view layer, which is the layer directly interacting with the user, is the data presentation layer

C:controller scheduling layer, refers to the view layer of the request forwarded to the service layer, the combined scheduling service layer to implement the view layer of the request, and the service layer of data back to the view layer

M:model data model, which refers to the service layer + data layer, which is often said Service+dao, is used primarily to implement business logic and return business data

The above theory believes that every developer of the Java EE has read the relevant introduction. For the view layer, we do not discuss, regardless of which view technology is used, its purpose is relatively simple, more easy to understand.

The main point here is C and M.

As a general practice, create a new action, create a new service interface, create a new DAO interface, create a new SERVICEIMPL implementation service interface, and create a new Daoimpl to implement the DAO interface.

Here we go back to the topic, why do you have to build so many classes and interfaces?

A lot of junior developers regardless of 3,721, superiors so requirements, so write, do not understand the flexibility, over time, think the web should be like this .....

Or, confusing the responsibilities of C and M, causing confusion in business logic and large amounts of code redundancy.

How: the right approach

So what's the right thing to do?

One, the responsibility of a single, focused

As small as a method, a class, big to a module, and then big to a system, what it does should be single, it should only focus on one thing, a field.

Controller scheduler, since it is called the scheduler, there should be no complex business logic, its responsibility should be single, is responsible for the lower level of service module arrangement, implementation of the view layer data request.

Service layer, now known as the service layer, should focus on services, implement all business logic, call and combine DAO layer query methods, there should be no scheduling and direct DB requests.

Dao,database access Object, database access layer, focus on database access, there should be no business logic.

Second, modular

In front of the controller is responsible for scheduling, if I put all the business is written into a service method inside, action on a method, something else did not do, then this scheduling is not useless? (Service is the same, if there is no business logic, simply call the DAO method).

Demand is like a grotesque building, you have two choices:

1. Create a building of this shape directly, meet the demand, next time in the direct creation.

2. Slice and dice this grotesque building into regular-shaped bricks and then stitch together. Next time to continue slicing, slowly your hands of the rules more and more, your code will be more and more good writing, each new requirement, you just use the existing bricks with a little glue to stick together. At this time the real function of action,service can be manifested.

The building block here is the module, which can be a method, a class, a package complete function.

It's good to believe that way, but why do most people use the first way to write code?

Third, generalizing

After the responsibilities and modules discussed clearly, we consider, View/action/service/dao is what, can change a way of writing, when we in the stratification angle, in view of them, in fact they are only a level of division, the upper layer relies on the lower layer to provide services for the upper layer, The framework defines what we want to write in this n-tier. I can also define myself in four layers, five layers ... As long as the business needs, so this has formed a part of your own programming ideas.

The above three steps need a solid step by step, of course, it is difficult at first, perhaps more difficult than you usually write code, also slower, this time you need a quality: Virgo (Pursuit of the ultimate)! :)

Then: the final word

We all know that the Java World Tool Framework is many, for engineering development, focus on business, do not build wheels, good! But for developers themselves, it is easy to create a rigid thinking, easy to get started, the foundation is poor, improve the difficulty!

This should also be C programmer to turn Java easy, Java programmer to C difficult part of the reason it! After all, many old C programmers are themselves to maintain their own tool library, and this tool library is a code out of their own. Bao Jianfeng from sharpening out, the external environment of good WO often cause the foundation is not firm.

Often said lazy is a programmer's excellent quality, because the computer itself is lazy product. However, in the compaction of the foundation, must be bitter kungfu, stupid kungfu, the pursuit of the ultimate, all things ask more than a few why, you can have lazy capital.

Everything has two sides, too much, the golden mean is not equal to mediocrity!

The rigidity of thinking in software development