Nopw.c MVC plug-in mechanism analysis

Basic Principles

Application of plug-insProgramGenerally, the plug-in interface is defined first, and the DLL compiled by the plug-in is put into a fixed directory. The main program of the application can use the plug-in by loading the DLL that implements the plug-in interface. The same is true for nopcommerce, but as MVC web applications, there will be some differences. First, the DLL loading policies will be different for different levels of trust (full trust, medium Trust, the other is how to display the view in the plug-in.

 

Put the plug-in folder

The nopcommerce plug-in is placed under the Plugins directory of the home directory of the website. There are many folders under the Plugins. A plug-in class library is a folder. Modify the compilation output address in the plug-in class library to the plugins folder of the home directory of the website, so that the DLL generated by the plug-in can automatically be under the target folder. For example:

The other folder is the shadowcopy folder, which is located in the plugins/bin folder. Why shadowcopy?ArticleAs described in, nopcommerce refers to its implementation. It also details the trust level issues.

 

Website launch

Let's first look at the pluginmanager. initialize method. The following attributes are defined on the pluginmanager class to ensure that the initialize method of pluginmanager runs at the beginning of the website and runs earlier than application_start.

[Assembly: preapplicationstartmethod (typeof (pluginmanager), "initialize")]

Run initialization before application_startCodeThe main purpose is to allow the website application to reference the loaded DLL.

 

Core

Ipluginfinder. CS interface: interface for obtaining plug-in information. Register this interface with NOP. Web. Framework. dependencyregistrar in IOC. The system is loaded into the memory when it is started.

Iplugin. CS: The operation interface of the plug-in. It mainly includes setting the property information of the plug-in, installing the plug-in interface, and uninstalling the plug-in interface.

Baseplugins. CS implements iplugin. CS.

The entity class of the plugindescriptor. CS plug-in contains the version, description, type, file name, author, and a series of states of the plug-in.

Pluginfileparser. CS contains the entity Operation Method for the plug-in, mainly the description of the write plug-in.

Pluginfinder. CS load all plug-ins and obtain their information.

For the main class managed by pluginmanager. CS plug-in, see the comments in it. Its plug-in mechanism should refer to umbraco CMS.

 

Load plug-ins

Load the description of the plug-in first. Each plug-in defines a plug-in extension file, which is defined by the extension file description.txt. The name is also agreed and cannot be another name. Description.txt in the plug-in library to describe the plug-in. The format of the lifecycle field in descriptionis fixed. pluginmanagerconverts the description.txt file to the plugindescriptor class and stores it in the memory. The displayorder field in description indicates the order of this plug-in for display on the interface. After obtaining all plug-ins, the plugin will go to installedplugins.txt. in installedplugins.txt, there will be check files that have been installed. If not, it will not be installed. The plugindescriptor. Installed attribute describes this information.

Copy the DLL to be loaded to the plugins/bin folder. Of course, all DLL files must be inherited from the iplugin interface. load the DLL at home and use buildmanager. addreferencedassembly loads the DLL into the website application. Note that buildmanager. addreferencedassembly must be included in the application_prestartinit process of the website program, that is, before application_start. The plug-ins to be referenced are all put under plugins/bin and referenced by CLR. The Assembly reference of the referenced plug-in will be saved in the static list of pluginmanager referencedplugins. The initialize method of pluginmanager ends here.

 

Display the plug-in on the Interface

For example, when defining a plug-in, we define a type of plug-in, such as the delivery method. When defining the plug-in, we will inherit two interfaces, one is the iplugin interface and the other is the ishippingmethod interface. You can use the pluginfinder. getplugins <t> (). tolist () method to obtain the delivery method plug-in. Pluginfinder searches for pluginmanager. referencedplugins in the previous step. The ishippingmethod instance is returned. Nopcommerce has a TXT file: installedplugs.txt. Only the plug-in will be loaded to the interface. You can add the plug-ins that ultimately need to act on the website to this file on the nopcommerce check page.

 

 

 

Configure plug-ins

The admin website of nopcommerce can configure the plug-in. For example, you can configure display order and isactive. The main logic is to update the description.txt file of the plug-in and the attributes in iplugin. descriptor in the memory.

 

Define controller, action, and view in the plug-in

A slightly complex plug-in basically contains the interface and logic to be processed. Therefore, you can define the interface view and related controller and action of the plug-in the class library. When creating the controller and view, you do not have to define them according to the standard controllers folder and views folder. You can define your own style.

When the view is returned in the action, enter the view name, which must contain the namespace, for example:

ReturnView ("Nop. plugin. Payments. cashondelivery. Views. paymentcashondelivery. Configure", Model );
 

Because, in the compiled plug-in DLL, the view as the embedded resource will be compiled into a resource file named NOP. plugin. Payments. cashondelivery. Views. paymentcashondelivery. Configure. cshtml.

Nopcommerce saves the configuration information of some plug-ins to the database through the configure interface of some plug-ins. Then, retrieve it from the database when it is displayed on the front-end page.

 

Read embedded resource view

The plug-in is loaded into the application domain as a class library. When defining the view of the plug-in, you need to modify the attribute of the cshtml file to embedded resource. It is put into appdomain as an embedded resource. We can use virtualpathprovider to enable web applications to retrieve resources from the virtual file system. You can find related knowledge in this article. The implementation of nopcommerce is the same as that in this article. There is an embeddedviews folder in NOP. Web. framework class library in nopcommerce, which contains some classes for processing embedded views. Finally, you need to register in global. asax. The nopcommerce code is as follows:

//Register virtual path provider for Embedded viewsVaREmbeddedviewresolver = enginecontext. Current. Resolve <iembeddedviewresolver>();VaREmbeddedprovider =NewEmbeddedviewvirtualpathprovider (embeddedviewresolver. getembeddedviews (); hostingenvironment. registervirtualpathprovider (embeddedprovider );
 

 

 

 

Compile nopcommerce plug-in

Refer to the official documentation. One of the suggestions is very good, that is, copy the original plug-in and modify it above.

 

 

Extract some code of the nopcommerce plug-in. You can download it from here.