The emergence of frameworks, class libraries, and other concepts stems from people's desire for reuse. "Do not reinvent the wheel" has become a classic saying in the software industry. From the original reuse of the source code of a single function to the reuse of classes in object-oriented (usually in the form of a Class Library), to the binary component based on component programming (. net in the form of IL assembly) reuse, People reuse software abstract level is getting higher and higher. Now, frame reuse is another improvement in the abstraction layer. Frame reuse is not only the reuse of functions, but also the reuse of design.
1.1 differences between frameworks and Class LibrariesLet's first briefly talk about what is a class library )? The class library is a collection of classes. As long as we put reusable classes in a library, we can call it a class library. Many elements in a class library (such as classes, structures, interfaces, enumeration, and delegation) may have some associations, but these associations are usually used to support the complete expression of a class or interface concept. If we look at the class library from a higher perspective, we can find that the "complete concepts" in the class libraries are irrelevant or loose.
Furthermore, the Framework is a skeleton that encapsulates the control logic of the processing process in a certain field. Therefore, we often say that the framework is a semi-finished product application. Because there are so many fields, the frameworks must be targeted, for example, frameworks dedicated to solving underlying communication or medical applications. The framework also contains many elements, but the relationship between these elements is much closer than that between the elements in the class library. All elements in the framework work together to achieve a common goal.
A framework with no capabilities of 10 thousand can be applied to all kinds of fields and applications. The framework is very targeted and focuses on solving problems in a specific field, and is committed to providing general solutions for this particular area.
The differences between frameworks and class libraries are mainly manifested in the following aspects:
(1) In terms of structure, the framework is highly cohesive, while the class library is relatively loose.
(2) The framework encapsulates the control logic of the processing process, and the class library hardly involves any processing process and control logic.
It is precisely because the framework encapsulates the control logic of the processing process that makes the framework a skeleton of an application. The process and control logic in the framework need to be carefully designed because all applications that use the framework will reuse the design.
(3) The framework has the IOC (control reversal) capability, but the class library does not.
IOC, also known as the Hollywood model (Don't call us, we will call you ). For elements in a class library, it is usually called by our application. The framework has this capability to call the logic in our application when appropriate. This capability is achieved through frame extension points (or "slots")-specific applications inject their own logic through extension points, and when appropriate, the Framework calls the registered logic in this extension point. In fact, the event release and reservation mechanisms in. NET are representative examples of IOC.
(4) frameworks focus on specific fields, while class libraries are more common.
The framework focuses on the complete expression of solutions in a specific field, and the class library is almost not targeted at any specific field. For example, the communication framework mentioned in this book only applies to applications that need to build communications on the basis of TCP/UDP, while class libraries such as regular expressions can be used in different applications.
(5) The framework is usually built on the basis of many class libraries, and the class libraries generally do not depend on a framework.
To further classify frameworks, they can be divided into general frameworks and application frameworks based on the applicability of the frameworks ). The general framework can be used in different types of applications, and the application framework is only used in a specific type of applications.
For example, the orm framework Nhibernate is a general framework that can be used in all types of applications that need to address o/R ing. A financial framework is an application framework that is only used in financial applications.
In this case, the general framework solves the "common" issue that all types of applications are concerned with, and the application framework solves the concerns of a specific type of applications. Therefore, if we needBusiness LogicThe process is upgraded to an application framework. Compared with the general framework, the application framework requires more domain knowledge in the multi-target business field.
When implementing specific applications, you can combine one application framework with multiple universal frameworks, which is conducive to rapid and high-quality application development. For example, an application in a financial field can use a financial framework as an application framework to solve problems related to the financial business logic. nhib.pdf is used to solve data access, esframework is used for communication between distributed systems in applications.
Describes the hierarchical relationships between class libraries, frameworks, and applications.
Of course, an application can be built directly from the underlying API (such as. NET Framework) without any framework. This method may be feasible for micro-systems. However, for complex and large-scale applications, difficulties can be imagined.
After an application system selects a framework, what we need to do is to add the specific logic of the application where the framework provides the extension point, that is to say, "blood" and "meat" are used to fill the skeleton to get an "organism ".
The framework is usually used and tested repeatedly in practice, so the quality is guaranteed, this makes it possible to implement a more stable system with less time and less encoding. Of course, the framework is not a silver bullet. It cannot solve the fundamental problem of software complexity, but we have taken another step towards this ultimate ideal goal through it.
Note that the framework also limits the support of our system. Because when we decide to adopt a framework, we need to build our applications within the "box" restricted by this framework. Most of the time, this is not a problem, but if the implementation of our system goals is seriously affected due to framework restrictions, we need to consider whether we should discard this framework, or another framework of the same type.
The framework makes developing applications faster, with higher quality and lower costs. These benefits are self-evident. However, in the face of ever-changing software requirements, it is easy to design and implement a highly flexible and reusable framework!
The Framework comes from applications, but is higher than applications.
The framework is often produced in this way: we have a lot of experience in developing a certain type of application. we sum up the common features of this type of application and extract it to a high level, for reuse. This "high-level" thing is the prototype of the framework. With the accumulation of our experience, the framework will be constantly improved and developed.
The framework is a product of practice, rather than theoretical research in the laboratory. Therefore, the best way to design a framework is to extract and extract the framework from a specific application, aiming at providing a general solution for the same type of application! Then, the framework is used in the application and constantly corrected and improved during the use process.
One thing that deserves special attention is that, as the main point of all software architecture design is to weigh (a bit like art in this regard), the design of the framework is no exception, as mentioned above, while providing a skeleton for the application, the framework also defines a frame for our application. We can only use it in this limited world. Therefore, a good framework design should adopt a very appropriate trade-off decision, so that the framework can provide strong support for our applications while making fewer restrictions on our applications. Trade-offs are never a simple task, but there are a lot of framework design experience for our reference.
(1) do not make too many assumptions for the application!
There are too many assumptions about the framework for the application. A very specific phenomenon is that the framework goes beyond the proxy and takes the tasks that the application was supposed to do by itself. This is a typical thankless approach. The framework becomes simpler and easier to develop a specific application, but it adds unnecessary constraints and burden to other applications that want to use the framework.
(2) Use interfaces to ensure that all important implementations provided by the framework can be replaced.
After all, the framework is not an application, so the framework cannot consider the specific circumstances of all applications and ensure that the implementation of all important components can be replaced. This is very important, it allows the application to replace the default implementation of some components provided by the framework according to the actual situation. Using Interfaces to define the links between components and components in the framework improves the reusability of the framework.
(3) The framework should be concise, consistent, and focused.
The framework should be concise and should not contain things that are irrelevant to the Framework goal. Every component in the framework should exist to support the implementation of the Framework goal. Adding too many unnecessary elements (such as classes, interfaces, and enumeration) will make the framework hard to understand and try to transfer these elements that are not very important to the core objectives of the framework to the class library, this makes the framework clearer and the goal more concentrated.
(4) provide a common skeleton, but do not fix the skeleton structure so that the skeleton can be assembled.
For example, if it is for a service processing framework, the framework should not only provide a set of business processing processes that cannot be changed, but should "one-step" process, so that each step can be re-assembled, so that the application can change the default process of the framework according to the actual situation. The customization capability of this framework can greatly improve the reusability of the framework.
(5) constantly reconstruct the framework.
What is the secret to designing and implementing a high-quality framework? There is only one answer: refactoring and constant refactoring. Refactor the implementation code of the Framework, and even the design of the framework. The driving force of restructuring comes from several aspects. For example, we have a clearer understanding of the essential problems to be solved. When using the framework, we find that some components have unclear responsibilities and are difficult to use, the hierarchy of the framework is not clear enough.
1.4.2 how can it be called an excellent framework?The most important feature of an excellent framework is simplicity. This simplicity is not easy to obtain. Just as a good framework is not achieved overnight, to achieve this simplicity, the framework needs to be continuously refined and improved.The real reason for simplicity is that it captures the essence of the problem to be solved.. An excellent framework usually has the following features:
(1) Clear, concise, and consistent.
"Clarity" indicates that the framework structure is clear, the framework layers are clear, and the responsibilities of various classes and components in the framework are clear and clear.
"Conciseness" refers to the absence of irrelevant elements in the framework, and the responsibilities and objectives of various classes and components are very concentrated, this is the embodiment of the design principle of "high cohesion and low coupling.
"Consistency" usually brings about this benefit. Users of the framework can easily understand another part of the framework after they are familiar with a part of the framework. "Consistency" is usually reflected in the consistent naming rules, consistent naming meanings, and the Assembly and usage of components.
(2) Easy to use
Only easy-to-use frameworks can go further.
It is precisely because of its ease of use that framework users are likely to try this framework. After the trial is satisfactory, they may decide to use this framework. Even if a framework is powerful and difficult to use, framework users may not have the idea of trying it out.
The vitality of the framework stems from the continuous improvement and development of the framework. If no one uses the framework, it will not be the source of development and improvement. Just as friendly user interfaces are an indispensable part of excellent applications, ease of use is also an important feature of excellent frameworks.
(3) highly scalable and flexible
The framework is highly scalable to cope with thousands of changes in applications.
No framework can predict the needs of all applications. A universal framework does not exist. The idea of attempting to design and implement a 10 thousand-performance framework is absurd. The framework must have the capability of "always-changing", which can be achieved by reserving appropriate and sufficient extension points for the application.
The flexibility of the Framework is reflected in that the framework can be assembled and configured according to different applications, just as the framework is customized for the current application.
(4) Lightweight
"Lightweight" means that you only pay for the services you need, rather than the services you don't need. One obvious feature of a heavyweight framework is that if you need a complete set of package services, there is no problem, and the framework can satisfy you well; however, if you only need a small snack in this package, sorry, the framework will still impose a complete package for you. You must pay the full package fee.
An excellent framework should support the user's "on demand" principle. Framework users can freely "order" for assembly to meet their own needs.
(5) weak and invasive
The so-called "weak intrusion", the application using the framework can tryCommonYou do not have to use some special methods to adapt to the framework.
This may be a bit difficult to understand. We can give an example to illustrate it. In. net, the two main ways to implement the AOP (Aspect-Oriented Programming) mechanism are using proxy and dynamic proxy. The AOP framework implemented using proxy usually requires classes that require the AOP Interception Function.RequiredIt inherits from contexboundobject, while the AOP framework implemented by dynamic proxy has no such invasive requirements. We can still write application logic classes in the most common way, such frameworks dynamically generate the proxy object of the target object according to the configuration during runtime to achieve AOP interception. Therefore, we can say that the dynamic proxy-based AOP framework is more invasive than the proxy-based AOP framework.
Weak intrusion means that the framework has less interference with the application logic. Because the application logic classes are common classes, it is very convenient for application logic to be reused in another program, another program may adopt a completely different framework.
The emergence of frameworks, class libraries, and other concepts stems from people's desire for reuse. "Do not reinvent the wheel" has become a classic saying in the software industry. From the original reuse of the source code of a single function to the reuse of classes in object-oriented (usually in the form of a Class Library), to the binary component based on component programming (. net in the form of IL assembly) reuse, People reuse software abstract level is getting higher and higher. Now, frame reuse is another improvement in the abstraction layer. Frame reuse is not only the reuse of functions, but also the reuse of design.
1.1 differences between frameworks and Class LibrariesLet's first briefly talk about what is a class library )? The class library is a collection of classes. As long as we put reusable classes in a library, we can call it a class library. Many elements in a class library (such as classes, structures, interfaces, enumeration, and delegation) may have some associations, but these associations are usually used to support the complete expression of a class or interface concept. If we look at the class library from a higher perspective, we can find that the "complete concepts" in the class libraries are irrelevant or loose.
Furthermore, the Framework is a skeleton that encapsulates the control logic of the processing process in a certain field. Therefore, we often say that the framework is a semi-finished product application. Because there are so many fields, the frameworks must be targeted, for example, frameworks dedicated to solving underlying communication or medical applications. The framework also contains many elements, but the relationship between these elements is much closer than that between the elements in the class library. All elements in the framework work together to achieve a common goal.
A framework with no capabilities of 10 thousand can be applied to all kinds of fields and applications. The framework is very targeted and focuses on solving problems in a specific field, and is committed to providing general solutions for this particular area.
The differences between frameworks and class libraries are mainly manifested in the following aspects:
(1) In terms of structure, the framework is highly cohesive, while the class library is relatively loose.
(2) The framework encapsulates the control logic of the processing process, and the class library hardly involves any processing process and control logic.
It is precisely because the framework encapsulates the control logic of the processing process that makes the framework a skeleton of an application. The process and control logic in the framework need to be carefully designed because all applications that use the framework will reuse the design.
(3) The framework has the IOC (control reversal) capability, but the class library does not.
IOC, also known as the Hollywood model (Don't call us, we will call you ). For elements in a class library, it is usually called by our application. The framework has this capability to call the logic in our application when appropriate. This capability is achieved through frame extension points (or "slots")-specific applications inject their own logic through extension points, and when appropriate, the Framework calls the registered logic in this extension point. In fact, the event release and reservation mechanisms in. NET are representative examples of IOC.
(4) frameworks focus on specific fields, while class libraries are more common.
The framework focuses on the complete expression of solutions in a specific field, and the class library is almost not targeted at any specific field. For example, the communication framework mentioned in this book only applies to applications that need to build communications on the basis of TCP/UDP, while class libraries such as regular expressions can be used in different applications.
(5) The framework is usually built on the basis of many class libraries, and the class libraries generally do not depend on a framework.
To further classify frameworks, they can be divided into general frameworks and application frameworks based on the applicability of the frameworks ). The general framework can be used in different types of applications, and the application framework is only used in a specific type of applications.
For example, the orm framework Nhibernate is a general framework that can be used in all types of applications that need to address o/R ing. A financial framework is an application framework that is only used in financial applications.
In this case, the general framework solves the "common" issue that all types of applications are concerned with, and the application framework solves the concerns of a specific type of applications. Therefore, if we needBusiness LogicThe process is upgraded to an application framework. Compared with the general framework, the application framework requires more domain knowledge in the multi-target business field.
When implementing specific applications, you can combine one application framework with multiple universal frameworks, which is conducive to rapid and high-quality application development. For example, an application in a financial field can use a financial framework as an application framework to solve problems related to the financial business logic. nhib.pdf is used to solve data access, esframework is used for communication between distributed systems in applications.
Describes the hierarchical relationships between class libraries, frameworks, and applications.
Of course, an application can be built directly from the underlying API (such as. NET Framework) without any framework. This method may be feasible for micro-systems. However, for complex and large-scale applications, difficulties can be imagined.
After an application system selects a framework, what we need to do is to add the specific logic of the application where the framework provides the extension point, that is to say, "blood" and "meat" are used to fill the skeleton to get an "organism ".
The framework is usually used and tested repeatedly in practice, so the quality is guaranteed, this makes it possible to implement a more stable system with less time and less encoding. Of course, the framework is not a silver bullet. It cannot solve the fundamental problem of software complexity, but we have taken another step towards this ultimate ideal goal through it.
Note that the framework also limits the support of our system. Because when we decide to adopt a framework, we need to build our applications within the "box" restricted by this framework. Most of the time, this is not a problem, but if the implementation of our system goals is seriously affected due to framework restrictions, we need to consider whether we should discard this framework, or another framework of the same type.
The framework makes developing applications faster, with higher quality and lower costs. These benefits are self-evident. However, in the face of ever-changing software requirements, it is easy to design and implement a highly flexible and reusable framework!
The Framework comes from applications, but is higher than applications.
The framework is often produced in this way: we have a lot of experience in developing a certain type of application. we sum up the common features of this type of application and extract it to a high level, for reuse. This "high-level" thing is the prototype of the framework. With the accumulation of our experience, the framework will be constantly improved and developed.
The framework is a product of practice, rather than theoretical research in the laboratory. Therefore, the best way to design a framework is to extract and extract the framework from a specific application, aiming at providing a general solution for the same type of application! Then, the framework is used in the application and constantly corrected and improved during the use process.
One thing that deserves special attention is that, as the main point of all software architecture design is to weigh (a bit like art in this regard), the design of the framework is no exception, as mentioned above, while providing a skeleton for the application, the framework also defines a frame for our application. We can only use it in this limited world. Therefore, a good framework design should adopt a very appropriate trade-off decision, so that the framework can provide strong support for our applications while making fewer restrictions on our applications. Trade-offs are never a simple task, but there are a lot of framework design experience for our reference.
(1) do not make too many assumptions for the application!
There are too many assumptions about the framework for the application. A very specific phenomenon is that the framework goes beyond the proxy and takes the tasks that the application was supposed to do by itself. This is a typical thankless approach. The framework becomes simpler and easier to develop a specific application, but it adds unnecessary constraints and burden to other applications that want to use the framework.
(2) Use interfaces to ensure that all important implementations provided by the framework can be replaced.
After all, the framework is not an application, so the framework cannot consider the specific circumstances of all applications and ensure that the implementation of all important components can be replaced. This is very important, it allows the application to replace the default implementation of some components provided by the framework according to the actual situation. Using Interfaces to define the links between components and components in the framework improves the reusability of the framework.
(3) The framework should be concise, consistent, and focused.
The framework should be concise and should not contain things that are irrelevant to the Framework goal. Every component in the framework should exist to support the implementation of the Framework goal. Adding too many unnecessary elements (such as classes, interfaces, and enumeration) will make the framework hard to understand and try to transfer these elements that are not very important to the core objectives of the framework to the class library, this makes the framework clearer and the goal more concentrated.
(4) provide a common skeleton, but do not fix the skeleton structure so that the skeleton can be assembled.
For example, if it is for a service processing framework, the framework should not only provide a set of business processing processes that cannot be changed, but should "one-step" process, so that each step can be re-assembled, so that the application can change the default process of the framework according to the actual situation. The customization capability of this framework can greatly improve the reusability of the framework.
(5) constantly reconstruct the framework.
What is the secret to designing and implementing a high-quality framework? There is only one answer: refactoring and constant refactoring. Refactor the implementation code of the Framework, and even the design of the framework. The driving force of restructuring comes from several aspects. For example, we have a clearer understanding of the essential problems to be solved. When using the framework, we find that some components have unclear responsibilities and are difficult to use, the hierarchy of the framework is not clear enough.
1.4.2 how can it be called an excellent framework?The most important feature of an excellent framework is simplicity. This simplicity is not easy to obtain. Just as a good framework is not achieved overnight, to achieve this simplicity, the framework needs to be continuously refined and improved.The real reason for simplicity is that it captures the essence of the problem to be solved.. An excellent framework usually has the following features:
(1) Clear, concise, and consistent.
"Clarity" indicates that the framework structure is clear, the framework layers are clear, and the responsibilities of various classes and components in the framework are clear and clear.
"Conciseness" refers to the absence of irrelevant elements in the framework, and the responsibilities and objectives of various classes and components are very concentrated, this is the embodiment of the design principle of "high cohesion and low coupling.
"Consistency" usually brings about this benefit. Users of the framework can easily understand another part of the framework after they are familiar with a part of the framework. "Consistency" is usually reflected in the consistent naming rules, consistent naming meanings, and the Assembly and usage of components.
(2) Easy to use
Only easy-to-use frameworks can go further.
It is precisely because of its ease of use that framework users are likely to try this framework. After the trial is satisfactory, they may decide to use this framework. Even if a framework is powerful and difficult to use, framework users may not have the idea of trying it out.
The vitality of the framework stems from the continuous improvement and development of the framework. If no one uses the framework, it will not be the source of development and improvement. Just as friendly user interfaces are an indispensable part of excellent applications, ease of use is also an important feature of excellent frameworks.
(3) highly scalable and flexible
The framework is highly scalable to cope with thousands of changes in applications.
No framework can predict the needs of all applications. A universal framework does not exist. The idea of attempting to design and implement a 10 thousand-performance framework is absurd. The framework must have the capability of "always-changing", which can be achieved by reserving appropriate and sufficient extension points for the application.
The flexibility of the Framework is reflected in that the framework can be assembled and configured according to different applications, just as the framework is customized for the current application.
(4) Lightweight
"Lightweight" means that you only pay for the services you need, rather than the services you don't need. One obvious feature of a heavyweight framework is that if you need a complete set of package services, there is no problem, and the framework can satisfy you well; however, if you only need a small snack in this package, sorry, the framework will still impose a complete package for you. You must pay the full package fee.
An excellent framework should support the user's "on demand" principle. Framework users can freely "order" for assembly to meet their own needs.
(5) weak and invasive
The so-called "weak intrusion", the application using the framework can tryCommonYou do not have to use some special methods to adapt to the framework.
This may be a bit difficult to understand. We can give an example to illustrate it. In. net, the two main ways to implement the AOP (Aspect-Oriented Programming) mechanism are using proxy and dynamic proxy. The AOP framework implemented using proxy usually requires classes that require the AOP Interception Function.RequiredIt inherits from contexboundobject, while the AOP framework implemented by dynamic proxy has no such invasive requirements. We can still write application logic classes in the most common way, such frameworks dynamically generate the proxy object of the target object according to the configuration during runtime to achieve AOP interception. Therefore, we can say that the dynamic proxy-based AOP framework is more invasive than the proxy-based AOP framework.
Weak intrusion means that the framework has less interference with the application logic. Because the application logic classes are common classes, it is very convenient for application logic to be reused in another program, another program may adopt a completely different framework.
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
