纸壳CMS的插件加载机制

纸壳CMS是一个开源的可视化设计CMS,通过拖拽,在线编辑的方式来创建网站。

GitHub

https://github.com/SeriaWei/ZKEACMS.Core

欢迎Star,Fork,发PR。:)

插件化设计

纸壳CMS是基于插件化设计的,可以通过扩展插件来实现不同的功能。如何通过插件来扩展,可以参考这篇文章:

http://www.zkea.net/codesnippet/detail/zkeacms-plugin-development.html

纸壳CMS的插件是相互独立的,各插件的引用也相互独立,即各插件都可引用各自需要的nuget包来达到目的。而不用把引用加到底层。

插件存放目录

纸壳CMS的插件的存放目录在开发环境和已发布的程序中是不一样的。在开发环境,插件和其它的项目统一放在src目录下:

而发布程序以后,插件会在wwwroot/Plugins目录下:

所以,如果在开发过程中要使用插件目录时,需要使用特定的方法来获取真实的目录,如:

PluginBase.GetPath<SectionPlug>()

相关代码

有关插件用到的所有相关代码,都在 EasyFrameWork/Mvc/Plugin 目录下:

插件加载

纸壳CMS在程序启动时加载所有启用的插件Loader.cs:

public IEnumerable<IPluginStartup> LoadEnablePlugins(IServiceCollection serviceCollection)
{
    var start = DateTime.Now;
    Loaders.AddRange(GetPlugins().Where(m => m.Enable && m.ID.IsNotNullAndWhiteSpace()).Select(m =>
    {
        var loader = new AssemblyLoader();
        loader.CurrentPath = m.RelativePath;
        var assemblyPath = Path.Combine(m.RelativePath, (HostingEnvironment.IsDevelopment() ? Path.Combine(AltDevelopmentPath) : string.Empty), m.FileName);

        Console.WriteLine("Loading: {0}", m.Name);

        var assemblies = loader.LoadPlugin(assemblyPath);
        assemblies.Each(assembly =>
        {
            if (!LoadedAssemblies.ContainsKey(assembly.FullName))
            {
                LoadedAssemblies.Add(assembly.FullName, assembly);
            }
        });
        return loader;
    }));
    Console.WriteLine("All plugins are loaded. Elapsed: {0}ms", (DateTime.Now - start).Milliseconds);
    return serviceCollection.ConfigurePlugin().BuildServiceProvider().GetPlugins();
}

AssemblyLoader

AssemblyLoader是加载插件DLL的关键,纸壳CMS主要通过它来加载插件,并加载插件的相关依赖,并注册插件。

namespace Easy.Mvc.Plugin
{
    public class AssemblyLoader
    {
        private const string ControllerTypeNameSuffix = "Controller";
        private static bool Resolving { get; set; }
        public AssemblyLoader()
        {
            DependencyAssemblies = new List<Assembly>();
        }
        public string CurrentPath { get; set; }
        public string AssemblyPath { get; set; }
        public Assembly CurrentAssembly { get; private set; }
        public List<Assembly> DependencyAssemblies { get; private set; }
        private TypeInfo PluginTypeInfo = typeof(IPluginStartup).GetTypeInfo();
        public IEnumerable<Assembly> LoadPlugin(string path)
        {
            if (CurrentAssembly == null)
            {
                AssemblyPath = path;

                CurrentAssembly = AssemblyLoadContext.Default.LoadFromAssemblyPath(path);
                ResolveDenpendency(CurrentAssembly);
                RegistAssembly(CurrentAssembly);
                yield return CurrentAssembly;
                foreach (var item in DependencyAssemblies)
                {
                    yield return item;
                }
            }
            else { throw new Exception("A loader just can load one assembly."); }
        }

        private void ResolveDenpendency(Assembly assembly)
        {
            string currentName = assembly.GetName().Name;
            var dependencyCompilationLibrary = DependencyContext.Load(assembly)
                .CompileLibraries.Where(de => de.Name != currentName && !DependencyContext.Default.CompileLibraries.Any(m => m.Name == de.Name))
                .ToList();

            dependencyCompilationLibrary.Each(libaray =>
            {
                bool depLoaded = false;
                foreach (var item in libaray.Assemblies)
                {
                    var files = new DirectoryInfo(Path.GetDirectoryName(assembly.Location)).GetFiles(Path.GetFileName(item));
                    foreach (var file in files)
                    {
                        DependencyAssemblies.Add(AssemblyLoadContext.Default.LoadFromAssemblyPath(file.FullName));
                        depLoaded = true;
                        break;
                    }
                }
                if (!depLoaded)
                {
                    foreach (var item in libaray.ResolveReferencePaths())
                    {
                        if (File.Exists(item))
                        {
                            DependencyAssemblies.Add(AssemblyLoadContext.Default.LoadFromAssemblyPath(item));
                            break;
                        }
                    }
                }
            });

        }

        private void RegistAssembly(Assembly assembly)
        {
            List<TypeInfo> controllers = new List<TypeInfo>();
            PluginDescriptor plugin = null;
            foreach (var typeInfo in assembly.DefinedTypes)
            {
                if (typeInfo.IsAbstract || typeInfo.IsInterface) continue;

                if (IsController(typeInfo) && !controllers.Contains(typeInfo))
                {
                    controllers.Add(typeInfo);
                }
                else if (PluginTypeInfo.IsAssignableFrom(typeInfo))
                {
                    plugin = new PluginDescriptor();
                    plugin.PluginType = typeInfo.AsType();
                    plugin.Assembly = assembly;
                    plugin.CurrentPluginPath = CurrentPath;
                }
            }
            if (controllers.Count > 0 && !ActionDescriptorProvider.PluginControllers.ContainsKey(assembly.FullName))
            {
                ActionDescriptorProvider.PluginControllers.Add(assembly.FullName, controllers);
            }
            if (plugin != null)
            {
                PluginActivtor.LoadedPlugins.Add(plugin);
            }
        }
        protected bool IsController(TypeInfo typeInfo)
        {
            if (!typeInfo.IsClass)
            {
                return false;
            }

            if (typeInfo.IsAbstract)
            {
                return false;
            }

            if (!typeInfo.IsPublic)
            {
                return false;
            }

            if (typeInfo.ContainsGenericParameters)
            {
                return false;
            }

            if (typeInfo.IsDefined(typeof(NonControllerAttribute)))
            {
                return false;
            }

            if (!typeInfo.Name.EndsWith(ControllerTypeNameSuffix, StringComparison.OrdinalIgnoreCase) &&
                !typeInfo.IsDefined(typeof(ControllerAttribute)))
            {
                return false;
            }

            return true;
        }
    }
}

注册插件时,需要将插件中的所有Controller分析出来,当用户访问到插件的对应Controller时,才可以实例化Controller并调用。

动态编译插件视图

ASP.NET MVC 的视图(cshtml)是可以动态编译的。但由于插件是动态加载的,编译器并不知道编译视图所需要的引用在什么地方,这会导致插件中的视图编译失败。并且程序也需要告诉编译器到哪里去找这个视图。PluginRazorViewEngineOptionsSetup.cs 便起到了这个作用。

由于开发环境的目录不同,对以针对开发环境,需要一个视图文件提供程序来解析视图文件位置:

if (hostingEnvironment.IsDevelopment())
{
    options.FileProviders.Add(new DeveloperViewFileProvider(hostingEnvironment));
}

loader.GetPlugins().Where(m => m.Enable && m.ID.IsNotNullAndWhiteSpace()).Each(m =>
{
    var directory = new DirectoryInfo(m.RelativePath);
    if (hostingEnvironment.IsDevelopment())
    {
        options.ViewLocationFormats.Add($"{DeveloperViewFileProvider.ProjectRootPath}{directory.Name}" + "/Views/{1}/{0}" + RazorViewEngine.ViewExtension);
        options.ViewLocationFormats.Add($"{DeveloperViewFileProvider.ProjectRootPath}{directory.Name}" + "/Views/Shared/{0}" + RazorViewEngine.ViewExtension);
        options.ViewLocationFormats.Add($"{DeveloperViewFileProvider.ProjectRootPath}{directory.Name}" + "/Views/{0}" + RazorViewEngine.ViewExtension);
    }
    else
    {
        options.ViewLocationFormats.Add($"/wwwroot/{Loader.PluginFolder}/{directory.Name}" + "/Views/{1}/{0}" + RazorViewEngine.ViewExtension);
        options.ViewLocationFormats.Add($"/wwwroot/{Loader.PluginFolder}/{directory.Name}" + "/Views/Shared/{0}" + RazorViewEngine.ViewExtension);
        options.ViewLocationFormats.Add($"/wwwroot/{Loader.PluginFolder}/{directory.Name}" + "/Views/{0}" + RazorViewEngine.ViewExtension);
    }
});
options.ViewLocationFormats.Add("/Views/{0}" + RazorViewEngine.ViewExtension);

为了解决引用问题,需要把插件相关的所有引用都加入到编译环境中:

loader.GetPluginAssemblies().Each(assembly =>
{
    var reference = MetadataReference.CreateFromFile(assembly.Location);
    options.AdditionalCompilationReferences.Add(reference);
});

原文地址:https://www.cnblogs.com/seriawei/p/9537867.html

时间: 2024-10-29 15:32:00

纸壳CMS的插件加载机制的相关文章

Qt5的插件机制(1)--Qt 框架中的插件加载机制概述

概述 Qt的源码中通过 Q<pluginType>Factory.Q<pluginType>Plugin 和 Q<pluginType> 这三个类实现了Qt的插件加载机制, 这个机制可用于加载特定种类的插件.比如通过 QPlatformIntegrationFactory\QPlatformIntegrationPlugin\QPlatformIntegration 三个类可以实现平台类QPA插件(PlatformIntegration)的加载,通过QPlatformI

android 插件加载机制之二

------本文转载自 Android插件化原理解析--插件加载机制 这一系列的文章实在是写的好! 5 Hook ClassLoader 从上述分析中我们得知,在获取LoadedApk的过程中使用了一份缓存数据: 这个缓存数据是一个Map,从包名到LoadedApk的一个映射.正常情况下,我们的插件肯定不会存在于这个对象里面: 但是如果我们手动把我们插件的信息添加到里面呢?系统在查找缓存的过程中,会直接命中缓存! 进而使用我们添加进去的LoadedApk的ClassLoader来加载这个特定的A

Android知识体系梳理笔记三:动态代理模式---插件加载机制学习笔记

静态代理模式 静态代理模式就是我们常说的代理设计模式,我们采用一个代理类调用原有的方法,且对产生的结果进行控制:举个例子:我们现在在玩一款网络游戏,需要打怪升级:太累就找个代理吧,一觉醒来就会发现我们已经当上CEO,迎娶白富美,天下第一了! 本来我们只能打怪,打怪-,但经过代理类增强,我们不仅可以打怪,还可以升级拿装备.就这样子了! 上代码: * 同一功能接口 public interface PlayNetGame { String beatMonster(); } 1 2 3 4 1 2 3

Android 插件化原理解析——插件加载机制

上文 Activity生命周期管理 中我们地完成了『启动没有在AndroidManifest.xml中显式声明的Activity』的任务:通过Hook AMS和拦截ActivityThread中H类对于组件调度我们成功地绕过了AndroidMAnifest.xml的限制. 但是我们启动的『没有在AndroidManifet.xml中显式声明』的Activity和宿主程序存在于同一个Apk中:通常情况下,插件均以独立的文件存在甚至通过网络获取,这时候插件中的Activity能否成功启动呢? 要启动

kettle插件加载流程

kettle插件加载流程 1.前言 kettle遵循着插件机制,基于插件使得kettle整个结构非常清晰,耦合性低,移植性强,特别是对kettle进行二次开发尤其方便,根据个人了解,扩展step类型的插件比较多,具体步骤可以参考:http://blog.csdn.net/d6619309/article/details/50020977  .通过了解插件的加载流程,不仅kettle的原理有深一层的认识,还有助于在进行二次开发遇到问题的时候进行定位(例如,最近遇到个情况就是通过kettle api

nodejs 模块以及加载机制,主要讨论找不到模块的问题

最主要的一个思想,加载模块无非就是找到模块在哪,只要清楚了模块的位置以及模块加载的逻辑那么找不到模块的问题就迎刃而解了.本文只是综合了自己所学的知识点进行总结,难免出现理解错误的地方,请见谅. nodejs的模块分类 1.原生模块:http  fs path等,这些模块都在源码包的lib目录下面,nodejs安装好之后是找不到这些模块的,都作为node.exe的一部分了,require这些模块永远没问题的,如果哪天出现问题了,直接重启电脑或者重装node.有什么疑问可以通过下载源码对这些原生模块

Android apk动态加载机制的研究(二):资源加载和activity生命周期管理

出处:http://blog.csdn.net/singwhatiwanna/article/details/23387079 (来自singwhatiwanna的csdn博客) 前言 为了更好地阅读本文,你需要先阅读Android apk动态加载机制的研究这篇文章,在此文中,博主分析了Android中apk的动态加载机制,并在文章的最后指出需要解决的两个复杂问题:资源的访问和activity生命周期的管理,而本文将会分析这两个复杂问题的解决方法.需要说明的一点是,我们不可能调起任何一个未安装的

MQTT---HiveMQ源码详解(四)插件加载

实现功能 将所有放在plugins目录下的所有符合plugin编写规范的plugin jar包加载到整个guice context中 实现步骤 1.找到所有plugin目录下的所有jar包 2.分别找到jar包中META-INF/services/com.hivemq.spi.HiveMQPluginModule文件读取第三方plugin配置的HiveMQPluginModule子类全路径 3.然后依次实例化它. 类图 这次的类图比上次的相比简单多了,加载机制也跟其他的有plugin机制的加载比

用Docker自动构建纸壳CMS

纸壳CMS可以运行在Docker上,接下来看看如何自动构建纸壳CMS的Docker Image.我们希望的是在代码提交到GitHub以后,容器镜像服务可以自动构建Docker Image,构建好以后,就可以直接拿这个Docker Image来运行了. Dockerfile 最重要的,就是Dockerfile中的定义了.先上代码: FROM microsoft/aspnetcore-build:2.0 AS builder WORKDIR /build # Copy all files COPY