一、前言在2.0的架构设计中，引入了插件的概念，目的就是为了解决代码臃肿问题，随着系统功能越来越多，System层的代码也越来越多，之前是以文件夹的方式区分功能模块，这样的话代码就过于集中，想找到某一个功能模块的代码就要翻好几个文件夹，不利于以后的开发和维护。所以在新的架构中，我将部分功能模块通过插件的方式提取出来，封装成类库形式的插件，这样System层如果需要哪个功能，就直接引用该功能模块的插件，我们调试代码中遇到问题也直接可以去对应功能模块的插件项目中查看代码并调试，非常方便。二、插件说明2.1核心插件2.1.1SimpleAdmin.Plugin.Core插件核心，被其他插件所引用，类

一、前言在2.0的架构设计中，引入了插件的概念，目的就是为了解决代码臃肿问题，随着系统功能越来越多，System层的代码也越来越多，之前是以文件夹的方式区分功能模块，这样的话代码就过于集中，想找到某一个功能模块的代码就要翻好几个文件夹，不利于以后的开发和维护。所以在新的架构中，我将部分功能模块通过插件的方式提取出来，封装成类库形式的插件，这样System层如果需要哪个功能，就直接引用该功能模块的插件，我们调试代码中遇到问题也直接可以去对应功能模块的插件项目中查看代码并调试，非常方便。二、插件说明2.1核心插件2.1.1SimpleAdmin.Plugin.Core插件核心，被其他插件所引用，类

一、说明在SimpleAdmin1.0版本中，我将整体项目结构分为三大块，分别为架构核心、业务模块和应用服务。随着1.0版本的封版，回去再看我之前的项目架构，也暴露了一些问题，比如在1.0版本中，Signalr和Mqtt只能二选一，这显然是不科学的，因为这两种虽然都可以作为消息通知，但是显然可以有更多的应用场景，所以如果两者只能用其一的话，显然整个项目架构就不灵活了。并且随着功能越来越多，太多的代码集合在一个应用中，仅仅以文件夹区分功能模块的话，会不会导致项目越来越臃肿？慢慢的就成了屎山了。这个时候我就想到了很多系统都会采用的插件式开发的模式，在业务模块中，除了基础的功能之外，一些拓展性功能采

一、说明在SimpleAdmin1.0版本中，我将整体项目结构分为三大块，分别为架构核心、业务模块和应用服务。随着1.0版本的封版，回去再看我之前的项目架构，也暴露了一些问题，比如在1.0版本中，Signalr和Mqtt只能二选一，这显然是不科学的，因为这两种虽然都可以作为消息通知，但是显然可以有更多的应用场景，所以如果两者只能用其一的话，显然整个项目架构就不灵活了。并且随着功能越来越多，太多的代码集合在一个应用中，仅仅以文件夹区分功能模块的话，会不会导致项目越来越臃肿？慢慢的就成了屎山了。这个时候我就想到了很多系统都会采用的插件式开发的模式，在业务模块中，除了基础的功能之外，一些拓展性功能采

SimpleAdmin✨没有花里胡哨，只有简单、稳定、高效✨如果您觉得有帮助，请点右上角"Star"支持一下谢谢?框架介绍??SimpleAdmin一个小而美的通用业务型后台管理系统。前端基于小诺2.0版本二次开发,采用Vue3+Vite+Vuex+JS,并在此基础上增加更人性化功能,后端采用.NET6/7+Furion,ORM采用Sqlsugar+单例模式,基于Redis的分布式缓存，采用RBAC+多机构的权限管理模式，实现全网最灵活的接口级别数据权限控制，集成国密加解密，导入导出、导入导出、批量修改等常用插件。后端代码注释覆盖率>90%，并配备手摸手教学文档，非常适合二次开发。将日常开发中

SimpleAdmin✨没有花里胡哨，只有简单、稳定、高效✨如果您觉得有帮助，请点右上角"Star"支持一下谢谢?框架介绍??SimpleAdmin一个小而美的通用业务型后台管理系统。前端基于小诺2.0版本二次开发,采用Vue3+Vite+Vuex+JS,并在此基础上增加更人性化功能,后端采用.NET6/7+Furion,ORM采用Sqlsugar+单例模式,基于Redis的分布式缓存，采用RBAC+多机构的权限管理模式，实现全网最灵活的接口级别数据权限控制，集成国密加解密，导入导出、导入导出、批量修改等常用插件。后端代码注释覆盖率>90%，并配备手摸手教学文档，非常适合二次开发。将日常开发中