Discussion on the Jacker of Web development Framework (I.)

Web

Without simple commercial application, a mature software is bound to have a certain degree of complexity. So a mature development framework is essential.

Introduce Jacker before, throw out some of my point of view, these views are some of my years of development and accumulation of formation, more is from Javaeye, here I also sent some posts, but see stickers mostly. Sometimes I really think that the accumulation of technology is not the most important, at most let you become a skilled mechanic just. The most important thing is the exchange of ideas, ideas, and the thoughts that dissolve into yourself.

I have been fortunate in the forum to see a lot of development ideas of the debate, in browsing these posts at the same time, they unconsciously have a position:

-Tiered development

The direct benefit of tiered development is separation of concerns, each development as long as the focus on their own level of development, is the development of professional quality software starting point.

No one development will be versatile, even if you understand each layer of development technology:

Html+css+javascript,java:struts+spring+hibernate,xml wait, do you dare to say that you are proficient in all this technology? I did five years of development, contact a lot, is very experienced, but frankly, I have not much interest in html,css, JavaScript mastery is only a focus, Using JavaScript to implement a clock or to complete a javascript tree by itself is simply unthinkable to me; hibernate also only focus on the configuration and operation of a single table, other places do not have time to do the drill; XML operations are part of the understanding of the next dom4j, What XPath doesn't look because it doesn't need to;

No versatile, versatile also can not be so used. Let him from the interface to the database implementation of a software module of each coding details, which is the quality of the software crime. "Versatile" developers have a high level of low, technical emphasis is also different, one person a stick to the end of the practice, the result is a system of the various modules of uneven quality, interface style is difficult to unify, code confusion, public Profile concurrency conflict serious ...

Therefore, the development to layered, web development should first be divided into the web layer, the business layer, and the Web layer will be subdivided with MVC architecture;

Tiered development requires layered architecture, and layered frameworks also force tiered development. If you insist on a person to do a module of the practice, then I think you still adopt jsp+javabean approach more appropriate, do not choose a layered structure, so that a person in the various layers jump to jump, will be dizzy;

One of the difficult points of layered development is management, how to assign tasks and the integration of each layer to the manager put forward higher requirements. This is another topic here is not much to say.

. Dto,web layer, Business layer

The DTO is data Transfer object. The DTO is primarily responsible for data delivery at the client (Web layer) and business layer. DTO Simple is some Java types, such as: String,integer, and even list,map, more is Pojo, the use of attributes to host data. Although only the attributes of the DTO are considered "anaemic" by some masters such as Martin Fowler, I think the DTO performs its duties well: Describes the business interface and transmits the business data. From the point of view of calling the business layer, I subdivide the DTO into the parameter pdto and the return value rdto. A DTO with attributes also describes the business well from the data perspective. So the DTO is essential;

The DTO effectively isolates the Web layer (the call layer) and the business layer, now there are "anemia" and "no anemia" controversy, I think the use of "anemia" such as the word is suspected, I would like to call such a DTO as a simple dto, simple dto adhere to a I think must adhere to the principle: hierarchical, Do not spread business logic to the Web layer. The purpose of layering is not to detach logic, but how can the Web layer Access objects with business logic? Including business constants, are web should eliminate access. And apparently "not anaemic" DTO does not intend to do so;

"Simplicity is beauty", so is the DTO.

In addition, the data Object Po in the DTO and O/R mapping (for example, the Pojo of Hibernate) is two different things, one describing the business and one responsible for the underlying database operations. If you choose to tier, do not try to use a PO instead of a dto to pass to the web layer, naturally less need to hibernate what open session in view. There are many reasons:

One benefit of tiering is synchronous development, and even the Web layer can be implemented before the background business, as long as the business interface is defined and the business layer has a mock mock implementation. Imagine when the database has not been established, where does your po come from and how can it be uploaded to the Web layer?
Another benefit of tiering is that each layer is replaceable and can be changed independently to respond to changing requirements, and the DTO as the object type that describes the business interface should be relatively stable, and this requires that your business layer operations do not need to be hibernate to use OJB one day, Can you also insist on using Hibernate's PO to describe the business interface? Or your O/R will never change, but frequent database reconfiguration causes your PO to change again, you dare to replace the relatively stable dto with PO?

Maybe you'll tell me that you don't need to sync development or layer replacement or layer independent change, then you should consider why you chose to tier, perhaps layered architecture is not what you want. :)