Liu Tianbei
1
People always prefer "big words". A way of expression, if you sound enough enough, write on the paper, you will be able to attract your attention, it will become a new favorite of many people. But it is also these words. After passing through too many people, after consumption, the original meaning is wear like a pattern on the coin: almost no one knows these sayings. In the IT industry, "Platform", "framework", "Architecture", etc. is what this kind of people see people. Almost every vendor is willing to come to one of them, even more for yourself. Over time, these statements seem to apply to all areas, all levels: all software systems are "platforms", all developers are self-sufficient "framework". The original meaningful "good words" have passed this competition and abuse, and can only attenuate the so-called "buzzwords" for the marketing people to taste. I want to let these words - "frame" -, reproduce youth. To complete such tasks, you must use the elimination. The Software Bible "Design Mode" has the following definitions: "A Framework is a set of cooperating classes That Make Up A Reusable Design for a Specific Class of Software (a frame, is a group of collaborative classes, for specific one Class software, framework constitutes a reusable design) ". This definition is mainly focused on object-oriented software development, but has basically given the core meaning of this word: the framework is a concept of software system, a concept in the development process, which emphasizes the completion of the design, and code repeat Use, and, a framework is mainly suitable for implementing a particular type of software system. In order to better illustrate what the frame is, you should still look at the frame is nothing. The frame is not a ready-to-use application system. It is still a semi-finished product, waiting for later people to do "secondary development", implement the specific application system. The frame is not a "platform". The latter concept is more floating and blur - a platform that people say, can be an operating system, an application server, a database software, a communication middleware, etc., so "platform" almost all systems Software collectively said. In the platform of the platform, the concept of the framework may be closest to the "application platform" recently said, but the platform mainly refers to the system software that provides specific services, while the framework is more focused on the design, development process, or can be said, The framework works by calling the service provided by the platform. The frame is not a toolkit / library / API. In many popular frames, there is a large number of libraries and APIs, but the API is not currently using the framework. When using the API, the developer completes the body part of the system and invokes the class library from time to time to implement a specific task. The framework constitutes a general, general system body part, "secondary developer" is just like a fill problem, according to the specific business, and completes a particular application in a particular application system. The frame is not a architecture. The architecture determines the design consideration of the overall structure, hierarchical division, and different parts. The frame is more specific and more than the technology. After determining the frame, the architecture also determines, and for the same architecture (such as the MVC in Web), it can be implemented by a variety of frames such as Apache Struts or Apache Velocity.
2
So, in the development of enterprise application system, what is the meaning of the framework? To clarify this, you will probably take a look at the evolution of software development in this field. Before the computer is applied, only a few large enterprises have affordable enterprise information system software, and the software development of this category has also been commissioned to be customized. After the corporate information infrastructure is gradually complete, most of the enterprises should implement the enterprise application system under the premise of the budget, and the development is customized by the previous way, which is unbearable in this type of enterprise. Therefore, for some systems that require a concise system, you will often purchase the SHRINK-WRAPPED SOFTWARE to solve the problem. However, the specific business of each company is difficult, demand is difficult, and ready-made software can only meet the most common situation and the most consistent operation (such as accounting system, website content release system, etc.), it is difficult for business processing for many clues. How to extract the commonality of different enterprise applications, reuse the completed design and code, give the best solution for typical scenes in the enterprise application system - this is a "general" problem; how to make an early first Completed software products adapt to extremely variable, complex business needs - this is a "special" problem. As a solution to this group of conflicts, many manufacturers have launched their own enterprise application framework. These frameworks are often "invariant" selected from a large number of commissioned project development, so it has strong universal and practicality. Currently, most of the mainstream enterprise application frameworks include ready-made solutions for the following issues: * Persistence: Implement data storage, processing, data and object mapping, data cache. * Transaction: Make sure a set of associated operations are normal, complete execution. * Security: Guarantee the security of the system, data security. * Load Balance: The system is available in a large number of concurrent access. * SYSTEM MONITORING / Management: Monitor system health and set system parameters. * Logging: Record system operation and exception, record specific user operations. * Application Integration: Integrate with other systems. * Authentication / Permission / Organizational Role Management: Managing system users, organizational powers, limit access to specific functions, specific data. * Domain Model: Managing the properties of the business object in the system, fields. * Business Logic / Rules: implement business rules and business logic. * Work Flow: Implement a multi-user, multi-link business processing process. * File Management: Manage documents to implement file delivery inside the system. * Report / Printing: Realize data printing, implementing the custom and output of the report. * Portal Solution: Release the company's related information, news, providing access to enterprise customers.
* Communication / Messaging: Messages inside the system, notifications; system and external roles (such as enterprise customers) interaction with different communication media (telephone, websites, emails, etc.). * Specific Industry / Domain Module (Business Modules): Realize a specific industry, a stream-related business module. In the above, in addition to the first four items, other parties themselves are specialized in software development. The role of the frame is to determine the specific techniques of each of the above factors, and specify their organization and collaboration in the system to give a complete enterprise application solution. The characteristics of the enterprise application frame are first, when the application framework is determined, the entire framework of the system is fixed. Therefore, the selection of the frame is often the primary problem of the program selection. Second, people often listen to the word "component development", and believe that the process of system construction is similar to the wood, it seems to be a ready-made component or module with glue code. In fact, when the framework is developed, the system's construction process is more similar to the fill in the blanks - the system skeleton has been completed, and the developer fills in the specific code, which is called by the system. "The Hollywood PrinciPle - Don't call US, We'll Call you" mentioned in "Design Mode" is very in line with us. Many frameworks also allow downstream vendors to develop system plugins to meet specific needs - this is another form of "fill". In addition, many tasks do not need to be implemented by programming for secondary developers who implement specific application systems. For example, add a new field to a business model, or set a new workflow, which can be operated by a simple graphical user interface (GUI) or modify the deployment descriptor (DD), or write The script is completed. That is, quite a large (not all) development tasks are implemented by declarative, rather than programming. The system tends to load related configurations at startup or runtime, which implements a specific function.
The company's application frame is a semi-finished product in the vegetable field. When we face either you kit, we will often take this time-saving compromise when they go to the restaurant. But the reason why choices is chosen, as it is definitely containing the trade-offs for the benefits and costs, implies complex sharp and disadweissing. Below we will also review the situation of the company's application framework: PROS: * Shorten the development cycle, there is no doubt that use the framework development, it is much more fast than everything from the head. By generalization and reuse mechanism, the frame can maximize the implementation of a particular application system. * Customization As described above, there are many functions based on the framework-based system through configuration instead of programming, which also brought certain convenience to the user. For example, IT staff within the company will have a new workflow settings. This is an ideal solution for changing business needs. * Do not re-inventing the wheel frame gives the best practices for a large number of typical scenes. At the time of specific development, it is better to use these mature and stable practices with its ignore the results of the former. This not only speeds up development schedule, but also enhances the quality and robustness of the system. * Maintainability / knowledge sharing is difficult to maintain by other manufacturers through the system that is committed to the development of the system. The framework is often a number of companies, a large number of developers' practices, so it can break the above barriers to a certain extent to enhance the maintenanceability of the system. When the frame user forms a community, it can also achieve higher levels of knowledge sharing. CONS: * Too many products have their own price. In a pack of supermarkets, there is always a seasoning that we can't use - but we have to pay for it. Similarly, in order to achieve general and general, the framework is more compact, and there are many specific applications. After the completion of the second development, it is only a specific implementation obtained, but pays for all the possibility of customization, paying all the features that cannot be used. This is a fairly embarrassing fact. * Too little framework is always a constraint. Just like semi-finished vegetables limits our cooking methods, the framework also limits the possibility of our practical application. When the frame itself is designed enough, we will not feel similar limits. However, the situation is often just opposite - in the face of a sufficiently special demand, the secondary developer has always a desire to break through the frame. The final solution is often a combination of a trick, compromise and frame patch. * Efficiency Said that the specific function is often implemented by configuration based on the frame-based system. Compared to hard coded, this can provide great flexibility, but also tend to sacrifice the efficiency of the runtime. * Locking a system using a specific framework is almost certainly locked on this manufacturer's product. In other words, the frame means the attitude of All or Nothing, it is difficult to emphasize, and each other is more difficult to migrate the application from a frame to another - this often requires all the rewrite of the system. * A framework of learning curve is also a dialect. To master the development of a specific framework, you have to be familiar with all the usage, ideas and weaknesses. For developers, this also means a relatively steep learning curve. 3
The disadvantages mentioned above are also defects in general development framework. For many popular business application frameworks on the market, the bigger problem is that the framework products are too high. I have also said elsewhere, and enterprise application system projects often do not rely on running installations, and then make simple settings, but a complex, long, constantly trying / modifying process, or said, more approximately a service. Not simple product sales. But the product (or semi-finished product) is too high, often from most of the development budget of the entire system, so that the total price of the program is brought about by the frame itself rather than the post-development. For projects that need to be in line with the original frame, it is necessary to develop a large number of projects that require a large number of projects themselves, which will certainly definitely lead to failures of the entire project. Software Engineering Master F. Brooks has expressed such a truth: no silver bullet / nsb. That means that there is no kind of multi-drug can dramatically improve the efficiency and quality of software development. The recent public opinion seems to be special and this classic discussion, and the special solution is made as a silver bomb. For enterprise application development, the frame-based development model is one of a variety of options. In many cases, this choice is good, but at the same time should pay attention to the risks of the following, it should not be thought that the selected framework must guarantee the success of the project. Many enterprise application projects are in the customer's own lack of normative enterprise management systems and qualified computer application levels. Customers do not have a formal business process, and they cannot express demand. I don't know what kind of application form is more reasonable for their own business: this demand is unclear, or the difficulties of demand violent changes are the crux of a large number of enterprise application development projects. Briefly, the success or failure of the enterprise application project is often "business", "technology", "management" three factors, and is simply introduced into the framework, and only some "technical issues" can be solved. If it is too optimistic to estimate the role of the frame, even think that it can solve any problems of any project, this can only be negative for all aspects (manufacturers, project developers, enterprise customers) in the art. My personal suggestion is: When building an enterprise application system, the budget / time limit is different for the application situation, and the requirements for system indicators are different, and there are multiple alternatives to choose from. When the demand is clear, fixed, there is a ready-made product to meet the needs, or when the company wants to eliminate a business bottleneck with a very low budget, it should be given priority; it should be given priority to the ready-made product; in demand, fixed, but it is difficult to be completely complete When you override, you can choose the application framework and implement the implementation of the qualified developer; if the demand is not clear, it will use the development of the source code to avoid high initial investment, and "Softnate" framework. Various limits are another idea to choose from. Or that is more than one, how to eat a meal, is the next time, buy semi-finished products or all from yourself, but also depending on the specific situation - I also hope that every company can eat delicious apps.
