Go Nopcommerce MVC plug-in mechanism analysis

This article transferred from: http://www.cnblogs.com/haoxinyue/archive/2013/06/06/3105541.html

Basic principle

Plug-in applications are generally defined plug-in interface, and then put the plugin compiled DLL into a fixed directory, the application main program by loading those implementation of the plug-in interface DLL to implement plug-in use.

Nopcommerce is the same, but as an MVC Web application there will be some difference, first of all the different levels of trust (full Trust,medium Trust) when the strategy to load the DLL will not be the same, but also how to display the view in the plugin problem.

Put the plugin folder

Nopcommerce plug-ins are placed in the plugins directory of the home directory of the website, plugins there are many folders, a plug-in class library is a folder.

In the plug-in class library, modify the address of the compiled output to the plugins folder of the Web site home directory, so that the DLL generated by the plugin can be automatically under the target folder. Such as:

The other folder is the Shadowcopy folder, just under the Plugins/bin folder. about why to use Shadowcopy, live This article is described, Nopcommerce is to refer to its implementation. The problem of trust level is also described in detail.

Website launch

Let's look at the Pluginmanager.initialize method first. By defining the following properties on the PlugInManager class, the Initialize method of PlugInManager is guaranteed to run at the beginning of the site, earlier than Application_Start.

[Assembly:preapplicationstartmethod (typeof (PlugInManager), "Initialize")]

Before Application_Start, the initialization code was run primarily so that the Web site application could refer to the loaded DLL.

Core class

IPluginFinder.cs interface: Gets the information interface of the plug-in, Nop.Web.Framework.DependencyRegistrar registers this interface in the IOC. The system is loaded into memory when it is started.

IPlugin.cs: Plug-in operation interface, mainly set the plugin's property information, install plug-in interface, uninstall plug-in interface.

BasePlugins.cs implements the IPlugin.cs method.

PluginDescriptor.cs plug-in entity class, contains the plug-in version, description, type, file name, author, and so on a series of States.

The PluginFileParser.cs contains the entity action method for the plug-in, mainly writing the plugin's descriptive information.

PluginFinder.cs loads all of the plugins and gets their information.

PluginManager.cs plug-in management of the main class, look inside the comments, its plug-in mechanism should be referred to umbraco this CMS.

Loading plugins

Load the description of the plugin first. Each plug-in must define a plug-in description file, the text file Description.txt to define, the name is also agreed, not other names.

Add Description.txt to the plugin's class library to describe the plugin. The format of text fields in description is fixed, and PlugInManager converts Description.txt files into Plugindescriptor classes, which are then stored in memory.

The Displayorder field in description represents the order of the plug-in for display on the interface.

After getting all the plug-in profiles, it will go to InstalledPlugins.txt inside to see, in InstalledPlugins.txt (Installedpluginsfilepath = "~/app_data/ InstalledPlugins.txt ") There are already installed check pieces,

No, there is no installation.

The Plugindescriptor.installed property describes this information.

Copy the DLLs that need to be loaded into the Plugins/bin folder, of course, to inherit from the IPlugin interface, Through Assembly.Load at home this DLL, and then use buildmanager.addreferencedassembly to load this DLL into the website of this application.

It is important to note that buildmanager.addreferencedassembly must be added to the application_prestartinit process of the early site program, that is, before Application_Start.

This is the plugin to be referenced is placed under the Plugins/bin, and is referenced by the CLR. The referenced plug-in's assembly reference will be saved in the static list of PlugInManager Referencedplugins. This concludes the Initialize method for PlugInManager.

Display plugins on the interface

For example, when defining a plugin, we define a type of plug-in, such as a shipping method. Then we will inherit 2 interfaces when we define the plug-in, one is the IPlugin interface, the other is the Ishippingmethod interface.

Pass pluginfinder.getplugins<t> () when you need to display the delivery mode plugin. ToList () method to get. Pluginfinder will go to the last step of the Pluginmanager.referencedplugins list to find out.

Returns an instance of Ishippingmethod. Nopcommerce has a TXT file: InstalledPlugs.txt.

Only the plugins inside this will eventually load into the interface. You can add a plugin to this file that will eventually need to be used for your website via the Nopcommerce Search Management page.

Configure Plug-ins

The Nopcommerce admin site can be configured for plugins. For example, display Order and isactive can be configured. The main logic is to update the plugin's Description.txt file and the in-memory properties inside the Iplugin.descriptor.

Define the Controller,action and view in the plugin

A slightly more complex plugin basically contains the interface and logic that you want to handle. So the plugin's interface view and related controller and action can be defined in the plugin's class library. In the establishment of controller and view, not necessarily according to the specification of the Controllers folder and Views folder to define, you can define your own style.

To return to the view in action, enter the name of the view that contains the namespace, for example:

Return View ("Nop.Plugin.Payments.CashOnDelivery.Views.PaymentCashOnDelivery.Configure", model);  

Because, in the compiled plug-in DLL, The view that is an embedded resource is compiled into a resource file called Nop.Plugin.Payments.CashOnDelivery.Views.PaymentCashOnDelivery.Configure.cshtml.

Nopcommerce The configuration information of some plug-ins into the database through the Configure interface of some plugins. It is then retrieved from the database when the foreground page is displayed.

Read the Embedded Resource View

The plug-in is loaded into the application domain as a class library. While defining the plugin's view, you need to modify the properties of the cshtml file to embedded Resource.

It is put into the AppDomain as an embedded resource.

We can use VirtualPathProvider to enable WEB applications to retrieve resources from the virtual file system, which you can find in this article, and the Nopcommerce implementation is the same as this article.

There is a embeddedviews folder in the Nop.Web.Framework class library in Nopcommerce that contains some classes that handle embedded view. Finally, you need to register in Global.asax. The code for Nopcommerce is as follows:

Register virtual path provider for embedded viewsvar embeddedviewresolver = enginecontext.current.resolve< Iembeddedviewresolver>();  New Embeddedviewvirtualpathprovider (Embeddedviewresolver.getembeddedviews ()); Hostingenvironment.registervirtualpathprovider (Embeddedprovider);    

Writing Nopcommerce Plugins

You can refer to the official documentation. One of the suggestions is very good, is copy the original plug-in, the above modification.

The Nopcommerce related plug-in part of the code was extracted, can be downloaded from here.

Go Nopcommerce MVC plug-in mechanism analysis