Understanding Enterprise Application Framework

Conversion from: http://blog.vsharing.com/sharptoolbox/a580795.htmlpeople are always fond of words ". If an expression sounds loud enough to attract attention on paper, it will become a new favorite of many people. However, after too many people pass and consume these words, the original meaning is worn out like a pattern on a coin: almost no one knows what these arguments mean. In the IT industry, "platform", "framework", and "architecture" are the main words that people love. Almost every vendor is willing to invite one or more of them to sell their own products. Over time, these arguments seem to apply to various fields and layers: All software systems are "platforms", and all developers are dedicated to their own "frameworks ". After such competition and abuse, the original "good words" can only be reduced to the so-called "buzzwords" for marketing people to play. I want one of these words-"Framework"-to reuse the dirt and reproduce the youth. To complete such a task, you must use the important code. The software industry bible "design patterns" defines the framework as follows: "A framework is a set of cooperating classes that make up a reusable design for a specific class of software (a framework, is a group of collaborative classes. for a specific type of software, the framework constitutes a reusable design )". Although this definition mainly focuses on object-oriented software development, it has basically given the core meaning of this term: Framework is a concept in the process of software system design and development, it emphasizes the complete design, Code And a framework is mainly used to implement a specific type of software system. To better describe what the framework is, you may want to see what the framework is. The framework is not a ready-to-use application system. It is still a semi-finished product, waiting for the future to do "secondary development" to implement the specific application system. The framework is not a "Platform ". The latter concept is more float and vague-a platform that people say can be an operating system, an application server, a database software, a communication middleware, etc, therefore, the "Platform" has become a general term for almost all system software. In the family of platforms, the concept of a framework may be the most similar to what is often said recently as an "Application Platform". However, a platform mainly refers to system software that provides specific services, the framework focuses more on the design and development process, or it can be said that the framework works by calling the services provided by the platform. The framework is not a toolkit/library/API. Currently, many popular frameworks include a large number of class libraries and APIs, but calling APIS is not just using framework development. When using APIs only, the developer completes the main part of the system and calls the class library from time to implement specific tasks. The framework constitutes a general and general system subject. The "secondary developer" is just like filling in a blank question to complete a distinctive and special part of a specific application system based on the specific business. The framework is not an architecture ). The architecture determines the overall structure, hierarchy, collaboration between different parts, and other design considerations. The framework is more specific than the architecture and focuses more on technical implementation. After the framework is determined, the architecture is also determined. For the same architecture (such as MVC in Web development), multiple frameworks (such as Apache struts or Apache velocity) can be implemented. So what is the significance of the Framework in enterprise application system development? To clarify this, let's take a look at the evolution of software development methods in this field. Before the popularization of computer applications, only a few large enterprises can afford enterprise information system software. This type of software development has also been commissioned by custom (custom-made software. After the informatization infrastructure of enterprises is gradually complete, most medium and small enterprises must implement enterprise application systems on the premise of low budget, and develop them one by one according to the previous methods, this type of enterprise is unacceptable. Therefore, for systems with simple requirements, we often purchase ready-to-use software (shrink-wrapped software) to solve the problem. However, it is difficult to unify the specific business needs of each enterprise. Off-the-shelf software can only meet the most common conditions and the most consistent operations (such as the accounting system and website content publishing system ), it is difficult to handle a large number of services. How can we extract the commonalities of different enterprise application systems to the maximum extent and reuse the completed design and code, provides the best solution for typical scenarios in enterprise application systems-this is a "general" problem; how to adapt an earlier software product to extremely changing and complex enterprise needs is a "special" issue. As a solution to this conflict, many vendors have released their own enterprise application frameworks. These frameworks are usually from a large number of delegated project development in the fine selection of the system "unchanged items", so it has a strong universality and practicality. Currently, mainstream enterprise application frameworks include off-the-shelf solutions to the following problems: * Persistence: data storage and processing, data and object ing, and data cache
* Transaction: ensures normal and complete execution of a group of associated operations.
* Security: ensures the communication and data security of the system.
* Load balance: keeps the system available when a large number of concurrent accesses are made.
* System monitoring/management: monitors the system running status and sets system parameters.
* Logging: records system running conditions and exceptions, and records specific user operations.
* Application Integration: integration with other systems and applications Program Integration.
* Authentication/permission/organization role management (authentication/authorization): * domain model: manages the attributes and fields of business objects in the system.
* Business logic/rules: implements business rules and business logic.
* Work Flow: implements multi-user and multi-link business processing processes.
* File Management: Manages documents to transfer files within the system.
* Report/print (reporting/printing): prints data and customizes and Outputs Reports.
* Portal solution: provides an access portal for enterprise customers.
* Communication/messaging: Internal Message notification and external interface * business modules of specific industries/domains: implement business modules related to specific industries and watershed. In the above aspects, apart from the first four projects that were mainly solved by the application server, other parts are specialized software development fields. The role of the framework is to determine the specific technical implementation of each of the above factors, and define their organization and collaboration methods in the system, so as to provide a complete enterprise application solution. The enterprise application framework features the following: After the application framework is determined, the entire architecture of the system, that is, the main structure, is fixed. Therefore, the selection of frameworks is often the primary issue of solution selection. Second, people often hear the word "Component-Based Development" and think that the system building process is similar to building blocks. It seems that the glue code is used to combine ready-made components or modules. In fact, when the framework is used for development, the system construction process is more similar to filling in the blank-the system skeleton has been completed, and developers fill in specific code for the system to call. The "Hollywood principle (the Hollywood principle -- don't call us, we'll call you)" mentioned in design patterns is very consistent with the situation we talked about. Many frameworks also allow downstream vendors to develop system plug-ins to meet specific needs-this is another form of "filling in the blank ". In addition, for secondary developers who implement specific application systems, many tasks do not need to be programmed. For example, to add a new field to a business model or set a new workflow, these tasks can be operated through a simple graphical user interface (GUI, or modify the deployment descriptor (dd), or write the script. That is to say, quite a few (rather than all) development tasks are implemented by declaring/configuring (declarative), rather than programming (programmatic. The system usually loads related configurations at startup or runtime to implement specific functions accordingly. The Enterprise Application Framework is a semi-finished product in the field. When we choose to cook on our own or eat at a restaurant, we tend to adopt this time-and-effort compromise. However, the reason for choice is that it must include a balance between benefits and costs, which implies a complicated pros and cons ). Next we will also review the enterprise application framework: * shorten the development cycle
Undoubtedly, framework-based development is much faster and more efficient than everything starting from scratch. Through the General (generalization) and reuse mechanisms, the framework can accelerate the implementation of a specific application system to the maximum extent. * Customization
As mentioned above, the Framework-based system has many functions implemented through configuration rather than programming, which also brings convenience to users. For example, after some training, IT personnel inside the enterprise can complete a new workflow setting on their own. This is an ideal solution for changing business needs. * Never re-invent the wheel
The Framework provides optimal practices for a large number of typical scenarios. In actual development, it is better to apply these mature and stable practices instead of ignoring previous achievements and re-thinking the answer. This not only accelerates the development progress, but also improves the system quality and robustness. * Maintainability/knowledge sharing
It is difficult for other vendors to maintain systems fully developed by entrusting them. The framework is often the result of many enterprises and a large number of developers, so it can break the above barriers to a certain extent and improve the maintainability of the system. When framework users form Community Then, we can share knowledge at a higher level. * Too many
Semi-finished products always have a price. In a bag of food prepared by the supermarket, we always don't have the spices we can use-but we have to pay for it. Similarly, in order to achieve universality and universality, the framework has a lot more content than the compact and appropriate specific applications. After secondary development, enterprises only get a specific implementation, but they have to pay for all customization possibilities and for all unused features. This is an embarrassing fact. * Too few
The framework is always a limitation. Just like semi-finished food limits our cooking methods and the Framework limits the possibility of practical application. When the framework itself is designed to be universally applicable, we will not feel similar restrictions. However, the situation is often the opposite-in the face of a special enough demand, secondary developers always have a desire to break through the framework. The final solution is often a combination of tricks, compromises, and framework patches. * Efficiency
As mentioned above, in a framework-based system, specific functions are often implemented through configuration. Compared with hard-coded, this provides great flexibility, but it often sacrifices the runtime efficiency. * Lock
A system using a specific framework is almost certainly locked on the products of the vendor. In other words, the framework means an all or nothing attitude. It is difficult to reconcile the two different frameworks and take advantages of each other, it is more difficult to migrate an application system from one framework to another-this usually requires that all the systems be rewritten. * Learning curve
A framework is also a dialect. To be proficient in development of specific frameworks, you must be familiar with all usage, ideas, and weaknesses. For developers, this also means a steep learning curve. The drawbacks mentioned above are also common defects of general development frameworks. For many popular enterprise application frameworks on the market, the bigger problem is that the price of framework products is too high. As I have said elsewhere, enterprise application system projects often cannot be completed by simply running the installer, but by a complicated, long, and constantly trying/modifying process, or, it is more similar to a service than a simple product sales. However, framework manufacturers' products (or semi-finished products) are too expensive, which often consumes most of the development budget of the entire system, so that the total cost of the solution is focused on the framework itself rather than later development. If the requirements do not conform to the original framework, a large number of projects need to be developed, or the requirements are not clear enough, this will almost certainly lead to the failure of the entire project. F. Brooks, a software engineering guru, once said that there is no silver bullet/NSB ). It means that none of them can dramatically improve the efficiency and quality of software development. Recently, many public opinions seem to be devoted to this classic discussion, and some special solutions are regarded as silver bullets. For enterprise application development, the Framework-based development mode is one of multiple options. In many cases, this kind of choice is good, but at the same time, we should pay attention to the risks that come with it, and we should not think that the project will be successful if we select the framework. The difficulty of many enterprise application projects lies in the customer's lack of standardized enterprise management systems and qualified computer application levels. Customers cannot clearly express their needs without forming business processes. They do not know what application forms are more appropriate for their own business: this unclear demand, or the dilemma of dramatic changes in demand, is the crux of a lot of enterprise application development projects. In short, the success or failure of enterprise application projects is often the result of the combination of "business", "technology", and "management", rather than simply introducing a framework, only some "technical problems" can be solved ". If you are too optimistic about the role of the Framework in it, or even think that it can solve any problem of any project, this is for all aspects of the field (vendors, project developers, enterprise customers) and can only play a negative role. My personal suggestion is: when building an enterprise application system, there are multiple alternative solutions for different application situations, different budgets/timelines, and different system metrics. When the demand is clear, fixed, and ready-to-use products fully meet the needs, or when enterprises want to eliminate a business bottleneck with a very low budget, ready-to-use products should be given priority; when the demand is clear and fixed, however, if it is difficult to be fully covered by off-the-shelf products, you can select an application framework and implement it by qualified developers. When the demand is not clear enough or you may feel that the demand will change dramatically, using the development source code application framework to avoid high initial investment and "soften" the constraints brought by the framework is another alternative. For example, how to eat a meal, whether it's going to get a restaurant, buy a semi-finished product, or do it all by yourself, but also depending on the specific situation-I also hope that every enterprise can have a delicious application dinner.