# 二次開發 二次開發注意事項 ### **應用和插件的區分** 通常的，我們可以把業務相對獨立的一個完整的功能，開發為插件。 開發插件的好處是系統具有非常好的擴展性。 基于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框架，對于插件的思想，是以會員賬戶的積分，余額（可提現、不可提現），傭金的增減業務調整為主體思想的。這樣，開發者開發的插件都可以通用，各種應用也可以通用。