Discussion on the Jacker of Web Development Framework (II.)

Web

Continue to throw out my point of view

. Web layer and business layer decoupling
The web layer implements a business operation by invoking the business layer. So the web is dependent on the implementation of the business layer. How do I decouple the two to develop independently? I tend to use a unified calling interface: Using a command string, adding a bunch of dto parameters to call the business, and then getting the DTO return value. The invocation of a business here is the execution of a command. OFBiz's service engine is such a practice, and very successful, this is a focus on the business concept. With a unified invocation interface, the development of the Web layer can be done independently, without relying on the business tier to compile. And there are more benefits to this approach: permissions, logs can be centrally managed, and, if possible, the distributed deployment business layer becomes convenient as all business is a command interface invocation.

. Mvc
MVC is a design pattern that is used in the web framework to enable us to effectively tier the Web layer: view+action
Struts,webwork is an MVC framework, and webwork is more flexible and elegant, amazing!
There are also more and more people who are familiar with MVC and accept MVC. Needless to say, Jacker also embraced MVC;

. XMLHTTP
From a problem-solving perspective, XMLHTTP is very powerful, you can choose it and rely entirely on it.
However, I think the rich client technology, has not really meaning the web development, I think server-side generation of dynamic pages is the real meaning of web development. The primary approach to web interaction is the post and get of form, not the post and get of the XML stream. Furthermore, direct access to objects and properties on the server side is more straightforward than doing an XML transformation and then parsing the data to the client. Of course, XMLHTTP as a technical supplement to enhance interface interaction, it is necessary.
And if you use rich client technology, it may not necessarily have to choose Xmlhttp,javascript I also played for many years of dealings, give me the feeling is always weak, especially debugging trouble, sometimes no chapter can be found.
Below I will say lightweight, completely based on XMLHTTP, undoubtedly need to have a huge JS library (backstage also have Java library) support, feel very heavy.

. Re-layering of view
MVC architecture, the display Layer view technology is a variety of options, too many, JSP may be the most used, the template language is also diverse, I divided into two categories: script template and simple template. Script template such as Velocity,freemarker, you can use a convenient script to define variables, operations and produce output, although a lot more clean than JSP, the script embedded how much still affect the cleanliness of the page, and the simple template is the idea of the page logic from the template to extract out, Template only with a fixed layout of the data to ensure that "WYSIWYG" of the development effect;
The introduction of a simple template to the view layer development will be transformative, simple template, the page does not have any code pollution, the direct benefit is the view of the development of the layering, art can also directly participate in the development of templates, help produce a professional quality of the interface effect.
A detailed introduction to the simple template shows my blog:http://blog.csdn.net/goldrain/.

. Light weight and flexibility
Broken down so many layers, each layer is a lot of technical framework to choose from, lightweight flexible solutions are naturally more popular. EJB is undoubtedly heavy, struts compared to webwork is stupid point, simple template Contrast script template, it is also light many, almost no grammar needs to learn.
Jacker can be easily run on Tomcat, and the framework options for each layer are:
View:eastm Simple Template (sub-project)
Web Mvc:webwork
Business decoupling and invocation: Jservice (sub project)
Business layer: Spring+hibernate

. Some views on ofbiz
OFBiz is undoubtedly a successful business framework, it is broad and profound, I wrote some things with OFBiz, but also to its entity Engine,service Engine and MVC framework of understanding. However, there are some different views, otherwise it is not to conceive their own framework here:
Attribute oriented or map oriented?
I call OFBiz is a map-oriented solution, service uses map to pass values, entity use map to store field values, use key to access values. In the Web layer, the parameters in the request are also transferred directly to the map for delivery, rather than to the object's property field first. The advantage of the map is that you can define many attribute classes, especially the DTO, but instead of using the Pojo method of hosting data with attributes, the map is less intuitive and rigorous, and the IDE can provide property method hints in Property object development, and map naturally does not. I tend to attribute-oriented programming, supplemented by map.
Component coupling or decoupling?
The OFBiz engine components are tightly coupled and difficult to extract and use alone. Entity Engine,service engine,web MVC architecture, workflows and so on are interdependent and difficult to split separate use.
Decoupling, maintaining the independence of the components, gives developers more choice, can choose to use the package, or select the part.