# 二次开发 二次开发注意事项 ### **应用和插件的区分** 通常的，我们可以把业务相对独立的一个完整的功能，开发为插件。 开发插件的好处是系统具有非常好的扩展性。 基于niucloud-admin框架体系而言，我们一般的把一个功能单元定义为两个类型（**应用、插件**）。非常深刻的理解应用和插件的定义，区分他们的区别，对于系统的可扩展性和开发方案的规划是非常重要的前提。 注意！在niucloud-admin框架体系，一个框架只支持单个应用安装多个插件。而非多应用！niucloud-admin框架不支持多应用。我们设计的初衷是简单，高效，可扩展。如果多应用模式，会成倍增加开发者的复杂度，导致系统最终无法维护。<br> **区分他们需要考虑两点** 第一，要开发的系统是否庞大，是否可能要修改整个niucloud-admin框架核心代码才能实现最终的业务功能，如果涉及到前面所述，我们一般会基于niucloud-admin框架进行全面的定制。这样的开发一般叫应用开发，插件是运行在应用上的功能扩展，插件是不能独立运行的，niucloud-admin框架是一个最基础的应用。一套niucloud-admin框架开发的系统，安装和运营只能有一个应用，一个应用可以安装多个支持本应用的插件。 第二，对于一些功能，相对单一，和其他系统单元没有过多的耦合性，也几乎没有业务黏连。或者，是实现某项具体的内核功能，这类型的功能，一般定义并开发为插件。比如阿里云短信，这一个系统功能，和任何业务系统没有关联，功能完全是独立的。再比如，开发一个刮刮乐的游戏，或者抽奖的小系统。这一类型的业务系统，一般的，仅仅会对会员账户的积分，佣金等操作。和具体的其他的业务几乎没有关联，这一类型的功能，一般开发为插件。插件的好处是便于流传，各种应用都可以加载，对于小开发商来说，可以从一个插件做起。 ### **二次开发中的继承和重写思想** 好的二次开发的系统，是兼容框架代码，不修改框架主体任何代码。并且不会因为二次开发之后，影响到系统与框架的同步升级的架构设计。这个一定要从项目设计阶段就考虑。 在此，牛哥讲解几种思维方式 1. 我们有这样一个业务需求，所有的功能都使用niucloud-admin框架本身的，只是会员列表、会员编辑的功能完全不符合自己的业务需求，因为我们希望实现的会员列表要有储值、累计消费金额、累计消费次数、当月消费金额、当月消费次数、而不要现在框架本身自带的手机号，注册方式等等等。对于这类型的开发，我们一定不要修改框架本身的功能，我们要做的是，我们新建一个插件，然后在插件中实现我们自己的会员列表和会员编辑，然后隐藏系统会员列表菜单，加载自定义的菜单并路由到自己编写的会员列表。这样，框架升级的时候，完全不影响二次开发的功能。完美实现二次开发与框架的兼容升级。 2. 我们有这样一个业务需求，手机端的个人中心和我想要的个人中心样式不同，要考虑几点 从api 接口，控制器，service考虑。一定有一个非常重要的概念，接口的功能唯一性、单一性。对于niucloud-admin本身查询会员中心的api接口可能是，[*http://127.0.0.1/adminapi/member/center*](http://127.0.0.1/adminapi/member/center), 我们二次开发一定不能修改这个接口，（一定记住！只要修改框架的任何东西，都可能会影响与官方的同步升级）。我们可以在插件中，来定义新的个人中心的接口比如 center\_v2, center\_v3, 然后自己写的页面调用此接口 对于前台而言，如果某个diy组件实现不了自己的样式和功能，那就重写一个组件，对于某个系统页面实现不了自己的页面需求，那就自己重写个页面，总归不能调整框架的任何东西。这些只是整体的一个复用思维方式，至于真的有复杂的系统，改写部分页面不如大动干戈，那就彻底的改造他。造成的后果就是升级的兼容性问题。 3. 具体的功能代码块，相互调用尽可能通过事件回调减少耦合 4. 整个niucloud-admin框架，对于插件的思想，是以会员账户的积分，余额（可提现、不可提现），佣金的增减业务调整为主体思想的。这样，开发者开发的插件都可以通用，各种应用也可以通用。