IoC, DI, and MVC in spring.net
Overview
Spring.net is an open-source service layer framework with powerful functions. It comes down to three features: Cross-section programming; IoC and DI; providing comprehensive framework support, this blog mainly talks about IoC and DI, as well as their support for the MVC framework.
IoC and DI
IoC, full name: Inversion of Control, Control Inversion; DI, full name: Dependency Injection, Dependency Injection. In short, IoC is the object to be created, and DI is the initialization when the object is created.
IoC and DI are equivalent to the abstract factory + reflection we usually write, but they are more powerful than the abstract factory, but the idea is the same, that is, decoupling. Through the abstract factory + reflection, we can decouple the upper and lower layers. Of course, the corresponding middle layer (Interface) provides the corresponding type guarantee for the lower layers, the IoC and DI provided by spring.net are also implemented in this way. However, when we use the spring.net framework, we do not need to write the corresponding Abstract Factory by ourselves, you do not need to maintain this class by yourself. spring.net has encapsulated the corresponding dll component for me. We only need to reference the corresponding component, then configure the corresponding configuration file to consider this function.
Support the MVC Framework
The MVC Framework is a framework of the UI Layer. Its Control class is used to accept requests and return data. Its processing of data business logic is handed over to the BLL layer (business logic layer) for processing, we use the dll component provided by spring.net to separate the U layer from the B layer.
If the UI Layer is not a MVC framework class, we will introduce the corresponding dll and configure the corresponding configuration file. Then, we will create a container object, then, you can give the corresponding key to get the desired object through the container object. This method is applicable to scenarios where the UI Layer does not have an architecture, while the UI Layer uses the MVC Architecture Program, we implement it in other ways. spring.net provides support for a comprehensive framework as described above. Therefore, we can know that, spring.net also provides the corresponding dll to connect with the MVC framework. The specific operation of this process: Define the corresponding attribute (IBLL interface type) in the control class. Then, through configuration in the configuration file, the corresponding attributes are initialized when you access the control class.
Configuration File Processing
When using the spring.net framework, we will write a lot of content in the configuration file, if the content is only in one web. if it is written in config, it will be very messy. At this time, we can create the corresponding xml file for the corresponding configuration. Of course, this requires the corresponding configuration, if we use this method, we need to note that we need to process the attributes of the xml file and get it to the UI Layer, because, the configuration file accessed by our program is based on the I-layer.
Summary
We create a program. We use the spring.net + M (EasyUI) VC + EF/nhib.pdf + T4 framework. Compared with a program that does not use layering and any architecture, the performance is, it must be the latter's efficiency. Because the Code Execution Process is small and the path is short, it is very fast. But why is there the architecture of the above-mentioned person, and many people think this architecture is still very good?
If we want to know the answer above, we need to analyze why the above two situations have emerged. Why? Because the types of programs we make are different, for Internet systems, the requirements for the system are fast execution speed, for enterprise-level business systems (OA \ ERP \ management systems, etc ), the requirements for the system are flexible response to changes in requirements. OK, so we can understand why there are so many frameworks and, there are still many people who are committed to the development of the framework and the reasons for the corresponding optimization work.
From the above analysis, we can know that for a program, it is good not to use the framework, but not to use the framework, but to use it properly.