The design idea
- The business system consists of several pages;
- Each page consists of several components;
- Page refers to a large range of functional modules, such as: monitoring, statistics, Settings;
- Component is a relatively independent, reusable function implementation, such as: map monitoring component, statistical report component, vehicle dialog component. The encapsulation granularity needs to be scaled according to the actual situation. It can be further refined to be independent of business processes and only provide functions similar to services, such as report output components and paging components. Can also rise to a large component, such as: personnel monitoring GIS display, including alarm view, track view;
- A composition of components is a page;
- The system has several roles, and different roles correspond to different component combinations and can be configured.
- In principle, all interfaces are a combination of components. The interface corresponding to the default role set by the system is not fixed, but configured as the default mode according to the above rules during initial system configuration. It could theoretically be reconfigured. Therefore, when a role wants to view the functions of other roles, you only need to add components or component combinations corresponding to the functions to the role.
- Components interact with each other, which is realized in the form of events, and specific events are designed for event mechanism. The main requirement is that each component can customize its own event, event corresponding content, event publishing (by publishing, other components can get the event, see: Twitter FlightJS framework);
- Basic component properties:
- The name of the
- describe
- Id
- The width of the
- highly
- Location coordinate position (left, top)
- The elements on the page exist as modules
- The module is responsible for data loading, display, interaction and operation in a certain area of the page
- A module has a life cycle within which business functions are implemented
- Modules communicate in the form of events
- Events must be managed in a unified manner
- Module events must have a way to tell what events are outside of them
- A page can load a layout, within which the layout is determined by HTML
- Modules can be nested, large (taking over the body), or small
- Module files must be contained in a folder (js, HTML, CSS files preferably together, subsequent skin may affect the storage of CSS files, can be adjusted appropriately
- Secondary pages are just module switches
- Modules are routing-driven with parameters passed to them
- A hash route can affect changes in multiple modules of a page
- To manage the system configuration, refer to the form of the registry
- The menu is also configurable. Different business scenarios have different menus. If the menu of different users is related to permissions, it needs to filter again through permissions;
Operational flow design
- The program starts with only the body tag in index.html;
- Load the first module viewPort, which is responsible for the overall layout, viewPort module according to the user’s choice, load different layout HTML templates;
- According to the module declaration label defined in the layout HTML template, instantiate the module component in the specified location, and call the module component init method, module component in the method to complete its internal logic (mainly responsible for loading data, display, add interaction, register events);
- Navigation menu module, according to the configuration + permissions display menu items;
- Home page aggregation module, according to user selection, load different information display module;
- On the second-level service page, a unique route is matched and the route is redirected.
Reference: http://flightjs.github.io/
What is missing
- Event management;
- Determination of data model;
- The component ID is determined;
- Organizational planning of internal files of components;
- Further refinement of routing (event distribution);
- Organization planning of CSS style files; (optimization)
- Data is obtained in the form of data components, but in fact, data acquisition in many places needs to be synchronized, so the use of scenarios are limited.
- The planarization of event names leads to mutual interference between events.
advantages
- Event-driven based on jquery DOM;
- Component concept;
- Wrapping interface code in the form of components;
- Decoupling is accomplished through events;
NETJ framework
Netease NETJ framework mentioned modular development plan reference: http://nej.netease.com/course/topic/dispatcher/
- Vertically adopt MVC architecture, horizontally adopt modular thinking.
- Modules communicate with each other through messages.
- Modules are divided into accessible modules (i.e. my page), private modules (i.e. sub-modules within a page);
- Modules are organized in a tree;
- There is a unified dispatcher (mapped to what I understand as a Sandbox, or Mediator);
- There is a history manager (for routing);
- Modules have a UMI (which I understand to be a module unique identifier);
-
The module is composed of CSS, JS and HTML, but netJ’s file storage is quite special, which is open separately, as shown in the following figure. And it specifies the style and script by adding two Textarea controls to the HTML.
-
Module (component);
- Declarative mode defines modules;
- Declaratively passing in module configuration parameters;
- Inter-module communication;
- Data acquisition, synchronous update;
- Controls;
- Module loading;
- Routing;
- Service;
-
Template engine;
angularjs
Google’s AngularJS framework. Reference:
- www.angularjs.cn/
advantages
- Declarative programming (extending DOM capabilities with the directive);
- MVVM mode, so that background data and interface almost completely decoupled;
- Elegant dependency injection mechanisms;
- Data binding, freeing up interface update code;
- The design of the module is not very clear, just a simple package;
- Parsing performance issues;
conclusion
The above idea is mainly a software design principles (SRP, LSP, DIP \ ISP, CARP, www.cnblogs.com/tomin/archi… The emphasis is on dependency inversion, for abstract design rather than concrete content. Based on the above ideas, the following similar requirements can be met:
- No matter what role, only need to design the function of the role, find out whether the existing system has realized the function component, if there is, reuse, no, according to the rules of new development components;
- The work of product design is as follows: define the function of the role, plan the relationship between components through interaction design, and obtain the prototype (the prototype is also based on the basic framework design, can not be unimaginative). If the existing specifications do not meet the prototype design, it can be considered to include rules;
- Developers don’t need to be familiar with all the features at first, but just need to understand the principles of the framework and develop the framework code;
- Subsequent functions corresponding to each role can be developed in parallel by increasing manpower;
- Role A can add functional components to obtain the functions of role B.
- The other?