niucloud-admin中继承和重写思想，建议收藏

好的二次开发的系统，是兼容框架代码，不修改框架主体任何代码。并且不会因为二次开发之后，影响到系统与框架的同步升级的架构设计。这个一定要从项目设计阶段就考虑。

在此，小编讲解几种思维方式

我们有这样一个业务需求，所有的功能都使用niucloud-admin框架本身的，只是会员列表、会员编辑的功能完全不符合自己的业务需求，因为我们希望实现的会员列表要有储值、累计消费金额、累计消费次数、当月消费金额、当月消费次数、而不要现在框架本身自带的手机号，注册方式等等等。对于这类型的开发，我们一定不要修改框架本身的功能，我们要做的是，我们新建一个插件，然后在插件中实现我们自己的会员列表和会员编辑，然后隐藏系统会员列表菜单，加载自定义的菜单并路由到自己编写的会员列表。这样，框架升级的时候，完全不影响二次开发的功能。完美实现二次开发与框架的兼容升级。

我们有这样一个业务需求，手机端的个人中心和我想要的个人中心样式不同，要考虑几点
从api 接口，控制器，service考虑。一定有一个非常重要的概念，接口的功能唯一性、单一性。对于niucloud-admin本身查询会员中心的api接口可能是，http://127.0.0.1/adminapi/member/center, 我们二次开发一定不能修改这个接口，（一定记住！只要修改框架的任何东西，都可能会影响与官方的同步升级）。我们可以在插件中，来定义新的个人中心的接口比如 center_v2, center_v3, 然后自己写的页面调用此接口
对于前台而言，如果某个diy组件实现不了自己的样式和功能，那就重写一个组件，对于某个系统页面实现不了自己的页面需求，那就自己重写个页面，总归不能调整框架的任何东西。这些只是整体的一个复用思维方式，至于真的有复杂的系统，改写部分页面不如大动干戈，那就彻底的改造他。造成的后果就是升级的兼容性问题。

具体的功能代码块，相互调用尽可能通过事件回调减少耦合

整个niucloud-admin框架，对于插件的思想，是以会员账户的积分，余额（可提现、不可提现），佣金的增减业务调整为主体思想的。这样，开发者开发的插件都可以通用，各种应用也可以通用。