Of Biz Of Biz Best Practices
The page you visited:
Some preface in front, lazy to turn over
Reducing code redundancy and code quantity: The most common is also the most efficient way to use code generation to achieve the purpose. In the OFBIZ, use the dynamic API to achieve this. Including Entity, Service, Workflow, Rule Engine, and Minilang. These dynamic APIs perform simple operations based on configuration and definition files. This is a wonderful work with the code generation. Without changing the code, you only need to modify the configuration file, you can adapt to changes in demand.
Data layout: The best utility is to use OFBIZ Entity Engine. For most applications, the entity engine can perform 99% of database operations very elegant. In some cases, the efficiency of the entity engine is not very high, so I recommend using JDBC code to check.
When using the entity engine, the names of the entities and domains use inline strings. This makes the code reading and maintenance easier. If you need to prepare a big MAP or EntityCondition? In the EE method, it is generally one line and looks clearer. Alternatively, in other rows before calling the EE method.
Use a simple, standardized data model. The usual data model can be directly extracted from the needs. The usual result is a highly standardized data model, which makes your life easier. When you need to bind the data, use the View-Entity feature to implement Join and Grouping and Summarizing.
Always use Primary Keys. When there is a more descriptive combined primary key, avoid using the automatically generated single main key. Always use the Relationship Definition to describe how the entity is used together, which is not only easier to obtain related data, but also confine the foreign key, and improve performance by automatic foreign key index.
Logical layer:
The best tool for calling the logic is OFBIZ Service Engine. Almost all business logic should be implemented as a service. This improves usability, making it easier to develop based components.
Although the service is flexible, of course, some service models are not suitable, and even commercial logic is not suitable. At some point, there is a need to call a script or Java method directly, and in these cases, the service model does not make sense, nor should it be used.
The service engine provides a lot of ways to achieve logic's implementation or business logic as a service, thereby reducing the amount of code. You can call, asynchronously call or call your logic according to Schedule. When you call a service, you don't need to know where it is, and how it is achieved. This makes it easier and more efficient to use remote services and different languages. Accessing the logic of different language implementations through the service engine is very important to effectively some special languages.
When defining services, we should try to make them simply. At any time, if a service is based on an entity, make sure to use the Autital Attributes Tag to create Attributes from the solid domain definition. Also, not using Attribute Tag to redefine Attribute, but only the Overrid Tag is used to describe those you want to change.
Always implement your service with the easiest and most appropriate language or tools. You can use many languages to implement services, such as Java, Beanshell, or any other BSF-compatible script language (such as Jython, JaCl, JavaScript, etc.), (Translation: I don't know if the Groovy does not work), OFBIZ workflow engine SIMPLE-MITHODS, processor, OFBIZ Minilang?, And other languages. Additional languages are easy to support, just write a simple Adapter. Always call remote logic through service engines. You can call remote services through a variety of mechanisms, including HTTP, SOAP, JMS, and other ways. You can easily increase the remote service call mechanism, just write a simple Adapter.
In most cases, you are willing to use the service engine to call your service to automatically WRAP to a transaction, so the entire operation is atomic, or success, or fail. Note If you call a service in a already existing transaction, it will automatically identify this transaction and use this transaction instead of another creation of a new transaction.
Express layer:
Always separate the input processing logic, the logic and view of the view data, and the views of the view. This makes it easy to reuse these logic not only in web applications, but also easily reuse in fat client applications. This makes your code easier to organize, it is easier to find a specific function code during debugging, easier to read.
For these three separate logic, we discussed separately.
Input processing logic input processing logic should always be associated with the request defined in the Controller.xml file, not the view binds. The input processing logic is usually implemented as a service, and the event processing is called by the service processing, which automatically passes the data or attributes in the request parameter to the service, and converts them into service definitions. Defined Object Type. In this way, when describing the parameters care, it is easier, just use the service definition, and is prepared by this frame for you.
Of course, in many cases, the input processing logic cannot be implemented as a service. There are many other event handling mechanisms for the logic associated with the request, so that you have more understanding of the context of the request. An example is that the file is uploaded, and another example is verification of special pre-processing and parameters prior to service processing. Note that you can call services in these custom event processing, and usually, usual logic should always be implemented as a service.
Always let the Control Servlet configuration to determine which request handler responds to a request. In most cases, the response is usually used to generate a view, but sometimes it will also use the request processing chain to obtain logical reuse and more stream control.
2. View data preparation logic
View data preparation logic always contacts the view template it prepared. This should be described by defining an action in the XML file through the page of JPublish. When a page is decomposed into multiple templates, this data preparation action should be contacted on each individual small template and prepare data for them. This makes the reuse and movement of the template and content tables in multiple pages.
View data preparation logic should be implemented with dynamic Script language, such as JavaScript, Beanshell ?, Jython or Time JaCl, making it easier to modify on the user interface. The usual data acquisition is implemented as a service, and these dynamic Script can call these services. This makes these functions easier to share and reuse. When preparing data, you can place the data object in the Context object, so that the view template can get these objects. All attributes of the Context object can be obtained by the template, as long as the template language supports it.
Note that when you use JSP as a view template, you can't use JPublish, so Action Facility cannot be used. Our suggestion for JSP is to prepare data using a single scriptlet on the top of the page. In this case, calling the Worker service or the Worker Java method to do most of the work, and make the page contain as few logic as possible.
3. View representation template
The best Template Engine used to generate html and other text is FreeMarker. It is similar to Jakarta's Velocity, but is more flexible and combined with other tools of the OFBIZ core framework. We strongly recommend using JPublish instead of running the FreeMarker? Template, so Actions can be linked to the page and template, and the page can also be modified with a normal template. Here we will describe how to use them best:
The view indicates that the template should be kept as simple as possible, and general information such as Header, Footer, Sidebars should use the Decoration mode in the runtime. A template file for modification will be described in the definition file of JPublish.
Always use views that best suits you. FreeMarker is a highly recommended tool for generating text, but in some cases, other tools may be more suitable. When you want to show the report, we recommend using Jasper Reports or DataVision. And combine these reports through View-MAP in a Controller.xml. If you want to generate tools such as Velocity or XSLT with other TEXT, we recommend that you use JPublish, especially when you want to modify them and have Actions to prepare data for these templates.
If you have a UI mode that is often reused, such as Forms, query data display, Tab, or menu, scalable tree view, currently we recommend using an XML file to describe these UI mode, then pass a rendering engine, or It is a tool such as XSLT / FreeMarker to convert to HTML or other output.
For most FORMs, the best way to behave is through the OFBIZ FORM WIDGET, which can accept an XML definition file that supports multiple UI types, and uses existing OFBIZ code such as service and entity definitions. Such code is smaller and is more easily maintained.
When FreeMarker cannot be used, we recommend using other dynamic template languages such as Velocity. When this is also available, we recommend using JSP. However, pay attention to the use of Action or modified templates when you use JSP, because it cannot run under JPublish, this is attributed to the JSP specification. Although you cannot use a modified template, you can use the combination view mode based on the REGON framework of OFBIZ. Region describes in Regions.xml. Note that these are not as easy as JPublish views, and they do not support Actions. But the Regions framework does provide a lot of flexibility, which is very useful in many cases. Before starting - methodological advice
Before you start to create anything, you must first define something. Any detail must be decided in some place. Because the difficulties of communication between individuals, and the difficulties involved in complex systems, we recommend the following practices:
Although these techniques are used in certain core function components of OFBIZ, they are also very meaningful for those who create software based on OFBIZ. The reason is that OFBIZ is a universal framework that is a collection of applications and software. In many cases, these applications can be used directly, but they can't meet any needs of anyone. Based on these reasons, it is used to meet specific areas, specific types of business, and products for specific end users, need to do more on the OFBIZ.
Methodology: Keep simple, but don't be too simple
There is countless software development methodology, and there is a new methodology at any time. In these hundreds, even thousands of documents about different methods, there are very good ideas. Usually we recommend "Agile" method, making things as simple as possible, but don't be too simple. For more information on "agile" development methods, see www.agilealliance.org
So the biggest problem is: What is the minimum collection that needs to be processed by the current project? The more complex demand, the more time and money you need. The more equivalent needs, you can't meet the risks of the project needs.
Minimum role
For any project, there are actually only two roles: buyers and sellers. For software projects or provided services, more common belongings are customer and developers. These two terms will be used herein. The term developer is used herein to refer to those who produce ultimately released products, while customers generally refer to those who ended paying products. In some cases, developers and customers are the same person, or the same group.
Here, it should be pointed out that an important part of the "customer" is the real user of the software. In the case of possible, it should be reviewed with these users to review the User Story and Use Cases.
