MVCSContex ：the big picture
1.應用程序的入口是一個類成為ContextView，這是一個Monobehavior實例化MVCSContext
2.用MVCSContext來執行各種綁定。
3.派發器是一個通信總線，允許你再程序發送消息，在mvcscontext中他們發送的是TimEvents， 或者你可以按照上面的步驟重寫Context 來使用Signals
4.命令類由TimeEvents或信號觸發，然后他會執行一些app邏輯。
5.模型存儲狀態
6.services與app意外的部分通信（比如接入的faebook）
7.界面腳本附加到物體上 ： 玩家與游戲的交互
8.Mediators(中介）也是monobehavior 但是他也可以將view部分和其他部分隔離開來
這張圖戰士了這些部分是如何一起工作的
大致介紹完了 下面來如何建立工程
一個ContextView開始
ContextView 是一個Monobehaviour 用來實例你的Context（上下文） MyFirstProjectRoot 是ContextView的子類， 這里是應用程序的開始
using System; using UnityEngine; using strange.extensions.context.impl; using strange.extensions.context.api;
namespace strange.examples.myfirstproject { public class MyFirstProjectRoot : ContextView { void Awake() { //Instantiate the context, passing it this instance. context = new MyFirstContext(this，ContextStartupFlags.MANUAL_MAPPING);
context.Start(); } } }
這里要使用 strange.extensions.context.impl 和 using strange.extensions.context.api 命名空間
ContextView定義了一個屬性稱為上下文當然是指我們上下文。我們只需要定義它是什么我們寫一個叫MyFirstContext的腳本。this 指的是MyFirstProjectRoot，他告訴Context 哪個GameObject被認為是ContextView。ContextStartupFlags.MANUAL_MAPPING表明一旦我們開始一切將會繼續。 調用context.Start()讓它付諸行動 。 如果不調用Start則不會繼續進行
- ContextStartupFlags.AUTOMATIC ： 上下文將自動映射綁定和啟動（默認的）
- ContextStartupFlags.MANUAL_MAPPING ： 上線文會啟動，然后在核心綁定后，在實例化或任何自定義綁定之前 將停止映射，必須調用Start()才可繼續進行
- ContextStartupFlags.MANUAL_LAUNCH ： 上線文會啟動，然后在核心綁定后 ， 在調用ContextEvent.START 或者類似的信號前停止。必須使用Launch（）繼續
The Context binds（上下文綁定）
Context(上下文)是所有綁定發生的地方,如果沒有綁定，Strange應用只是一堆斷開連接的部分。Context是為混亂帶來秩序的膠水。從我們擴展MVCSContext，我們得到了一大堆的核心綁定，MVCSContext是為了給我們所有我們需要干凈的結構 一個控制反轉風格的應用：一個注射（injector）、命令總線、模型和服務支持，和中介界面。
using System; using UnityEngine; using strange.extensions.context.api; using strange.extensions.context.impl; using strange.extensions.dispatcher.eventdispatcher.api; using strange.extensions.dispatcher.eventdispatcher.impl; namespace strange.examples.myfirstproject { public class MyFirstContext : MVCSContext { public MyFirstContext (MonoBehaviour view) : base(view) { } public MyFirstContext (MonoBehaviour view, ContextStartupFlags flags) : base(view, flags) { } protected override void mapBindings() { injectionBinder.Bind<IExampleModel>() .To<ExampleModel>() .ToSingleton(); injectionBinder.Bind<IExampleService>() .To<ExampleService>() .ToSingleton(); mediationBinder.Bind<ExampleView>() .To<ExampleMediator>(); commandBinder.Bind(ExampleEvent.REQUEST_WEB_SERVICE) .To<CallWebServiceCommand>(); commandBinder.Bind(ContextEvent.START) .To<StartCommand>().Once (); } } }
像你看到的那樣，我們擴展了MVCSContext，這意味着我們繼承其所有映射（探索它類的深度 ，你會發現它的有趣）。我們已經有一個injectionBinder和commandBinder和dispatcher調度員。注意,調度程序可以在整個應用程序,和CommandBinder耦合，所以任何事件派遣可以觸發回調也觸發命令commands和序列sequences。
這里的映射是完全符合你的期待如果你讀到的各種組件注入,我們映射一個模型和一個服務都是單例。我們將只有一個視圖(ExampleView)在這個例子中，我們將它綁定到一個中介(ExampleMediator)。最后,我們映射兩個命令。這兩個比較重要的是StartCommand綁定到一個特殊的事件:ContextEvent.START.這是事件觸發啟動你的應用。你需要綁定一些命令或者隊列到它身上想init()為進入你的應用程序。我們綁定了.Once()，一個特殊的方法，在一次結束時被解開Unbinds。
注意這里有一個postBindings（）方法。這是一個十分有用的地方放一些你需要在綁定之后運行的代碼。但是他運行在Launch（）之后，MVCSContext用這個方法去處理任何Views界面哪一個在寄存器中更早（在mapBindings之后被調用）。另一個明顯的和有用的情況 在postBindings（）中調用DontDestroyOnLoad（ContextView）。在你加載一個新的場景時用來保留ContextView（and the Context)。
A Command fires（一個命令被觸發）
ContextEvent.START 被處罰，因為它被綁上了StartCommand， 一個新的StartCommand實例將被實例化出來並且執行。
using System; using UnityEngine; using strange.extensions.context.api; using strange.extensions.command.impl; using strange.extensions.dispatcher.eventdispatcher.impl; namespace strange.examples.myfirstproject { public class StartCommand : EventCommand { [Inject(ContextKeys.CONTEXT_VIEW)] public GameObject contextView{get;set;} public override void Execute() { GameObject go = new GameObject(); go.name = "ExampleView"; go.AddComponent<ExampleView>(); go.transform.parent = contextView.transform; } } }
StartCommand 擴展 EventCommand 意味着這是固定的命令CommandBinder可以處理， 他繼承的所有東西都來自command 和 EventCommand。特別是，繼承EventCommand意味着你得到一個IEvent注入，並且你可以訪問dispatcher。
如果你只是擴展命令,您不會有自動訪問這些對象,但是你依舊可以手動注入他們
[Inject(ContextKeys.CONTEXT_DISPATCHER)] IEventDispatcher dispatcher{get;set;} [Inject] IEvent evt{get;set;}
注意所使用的兩種不同類型的注入。IEventDispatcher和GameObject 都是用名字創建多個實例。這是因為我們想引用這些對象的非常具體的版本。我們不希望是任意一個GameObject。我們需要一個標記像ContextView。我們也不接受任何舊IEventDispatcher。唯一一個將在上下文間通信，他標志為ContextKeys.CONTEXT_DISPATCHER。另一方面，Ievent是一個簡單的映射用於這個特殊的命令（技術上他映射到一個value)，所以沒有必要的名字。
依賴我們將使用在當前場景是ContextView，他們添加子視圖到它。
Execute()方法通過CommandBinder自動觸發。大多數情況下 ， 執行的順序是這樣的
- 實例化Command命令綁定到Ievent.type
- 注入依賴關系，包括Ievent本身
- 調用Excute（）
- 刪除Command命令
命令不需要立即清理干凈，但是我們將會得一點。如果你查看了Execute（）里面的代碼，你將會發現他是純粹的Unity。創建一個GameObject,附上MonoBehaviour，然后設置它的父親為ContextView。我們使用的是具體的MonoBehaviour（代碼），然而,恰好是一個Strange IView，自從我們在context中映射這個界面。
mediationBinder.Bind<ExampleView>().To<ExampleMediator>();
這個界面是自動調度的，這意味着一個新的ExampleMediator剛剛創建!
A View is mediated（一個界面被調度）
如果你花費了一些時間為Unity編寫代碼，你創建一個界面，你需要調用Monobehavior，但是重點在於那個界面沒有在屏幕上顯示的東西。我不打算花時間執行ExampleView代碼。你可以看下示例文件，如果怕你已經知道C#和Unity你不需要他。我只想引起兩位的注意力。首先：
public class ExampleView : View
通過擴展View，你將會得到連接每個View到Context的代碼。使用Strange 你不再需要擴展View或者重寫里面的方法。但是如果你不擴展View，你依舊需要實現IView 接口。這需要確保你MonoBehaviour上下文可以操作。
第二項指出
[Inject] public IEventDispatcher dispatcher{get; set;}
注意 我們注入IEventDispatcher。但是跟StartCommand不是同一個調度。仔細看看代碼第一個寫在EventCommand(我上面顯示)是這樣的
[Inject(ContextKeys.CONTEXT_DISPATCHER)] public IEventDispatcher dispatcher{get; set;}
通過命名注入,指定的命令使用常見的上下文調度員。這個界面不應該注入dispatcher。中介的目的是隔離應用程序的視圖 反之亦然Strange允許注入View。但這功能最好的時候嚴格限制，注入本地調度員與中介溝通很好。所以注入配置/布局文件(這是有用的,如果你發布到多個平台)。但如果你聽我的勸告，不要注入入一個模型或服務或其他池外擴展的視圖以及中介。
告訴你正確的方法：對於大多數開發人員來說，最難的是掌握整個框架的概念。一個視圖應該只顯示和輸入。當某些輸入發生，視圖應該通知媒體。中介Mediator(允許注入上下文調度員)抽象的觀點,關注與應用程序的其余部分。這個保護應用程序的視圖代碼，這通常和保護你的界面是混亂的，相反的情況是如此。
注意,基本視圖類使用標准MonoBehaviour處理程序 Awake(), Start(), and OnDestroy()。如果你重寫這些處理程序，確保你調用了base.Awake()等。這樣Strange才能正常運行。
觀察調度者
using System; using UnityEngine; using strange.extensions.dispatcher.eventdispatcher.api; using strange.extensions.mediation.impl; namespace strange.examples.myfirstproject { public class ExampleMediator : EventMediator { [Inject] public ExampleView view{ get; set;} public override void OnRegister() { view.dispatcher.AddListener (ExampleView.CLICK_EVENT, onViewClicked); dispatcher.AddListener (ExampleEvent.SCORE_CHANGE, onScoreChange); view.init (); } public override void OnRemove() { view.dispatcher.RemoveListener (ExampleView.CLICK_EVENT, onViewClicked); dispatcher.RemoveListener (ExampleEvent.SCORE_CHANGE, onScoreChange); Debug.Log("Mediator OnRemove"); } private void onViewClicked() { Debug.Log("View click detected"); dispatcher.Dispatch(ExampleEvent.REQUEST_WEB_SERVICE, "http://www.thirdmotion.com/"); } private void onScoreChange(IEvent evt) { string score = (string)evt.data; view.updateScore(score); } } }
在最上方 我們注入了ExampleView。這是調度者Mediator如何知道調度那個界面。介質可以知道很多關於他們的界面。中介通常被認為是“廢品(信口開河的)代碼”,因為它是非常特殊的細節視圖和應用程序。當然這個中介可以知道視圖有一個調度者和這個調度這個程序的事件成為ExampleView.CLICK_EVENT。通過監聽這個事件,中介建立了一個處理程序(onViewClicked())告訴其余的應用這個點擊意味着什么。視圖不應該發送REQUEST_WEB_SERVICE事件。界面只是界面。它應該像這樣派發事件HELP_BUTTON_CLICKED, COLLISION, SWIPE_RIGHT。這應該是Mediator中介者的工作，映射這些事件到應用程序的其余有意義的部分。如REQUEST_HELP MISSILE_ENEMY_COLLISION PLAYER_RELOAD.他后面的事件映射到命令,這些命令會調用幫助系統,計算分數增加(增加得分模型)或確定是否允許玩家重新加載。
OnRegister()和OnRemove（）方法像Mediator調度者的構造與析構函數。OnRegister（）在注入后發生。所以我經常用它來設置監聽和調用Init（）方法實例界面、OnRemove（）發生在Monobehavior的OnDestroy（）被調用之后。它觸發的時候你可以用來清理監聽。確定你移除了你的監聽，否則會產生不正確的垃圾回收。
最后注意 通過擴展EventMediator我們有公共的dispatcher。 調度者在總線監聽SCORE_CHANGE事件。
Another Command fires（其他命令觸發）
讓我們看回Context 這行有我們忽略的問題:
commandBinder.Bind(ExampleEvent.REQUEST_WEB_SERVICE).To<CallWebServiceCommand>();
這里的意思是任何時候公共的總線收到這個事件，它會啟動CallWebServiceCommand。但是他吸引你的注意力是因為通過不同的方法使用命令。
using System; using System.Collections; using UnityEngine; using strange.extensions.context.api; using strange.extensions.command.impl; using strange.extensions.dispatcher.eventdispatcher.api; namespace strange.examples.myfirstproject { public class CallWebServiceCommand : EventCommand { [Inject] public IExampleModel model{get;set;} [Inject] public IExampleService service{get;set;} public override void Execute() { Retain (); service.dispatcher.AddListener (ExampleEvent.FULFILL_SERVICE_REQUEST, onComplete); string url = evt.data as string service.Request(url); } private void onComplete(IEvent result) { service.dispatcher.RemoveListener (ExampleEvent.FULFILL_SERVICE_REQUEST, onComplete); model.data = result.data as string; dispatcher.Dispatch(ExampleEvent.SCORE_CHANGE, evt.data); Release (); } } }
我們監聽service，調用一個方法。我們使用事件中有效data數據來觸發mediator調度者service.Request（the url）。當service結束，他派發。觸發onComplate（）。我們取消監聽映射，設置一個值的模型，派發SCORE_CHANGE那個哪個調度者收到就做相應的處理。
但如果你一直密切關注你會記得，我之前提到過,命令后立即清理干凈在Execute（）完成時。所以為什么不是這個命令不會被垃圾收集。答案是最頂端調用Retain（）方法保留。Retain（）標志着這個命令為免除清理。這將會保持知道調用了Release()之后。顯然，這意味着調用了Release()是非常重要的，否則會造成運行中的內存泄露風險。
不要允許模型和服務監聽事件。 利用他們的調度者來監聽事件
Mapping Across Contexts（穿過Contexts的映射）
一般來說你要遵守上下文邊界。畢竟，它的邊界是有原因的 ：它允許應用程序的部分功能的隔離,使程序變得更加模塊化。但有時有一些對象，也許是一個模型、一個服務、或者一個信號需要需要跨多個上下文訪問。
injectionBinder.Bind<IStarship>().To<HeartOfGold>().ToSingleton().CrossContext();
添加CrossContext()信號綁定需要實例化穿過context邊界。它將提供給所有孩子contexts。注意,也可以覆蓋一個CrossContext綁定。如果你隱射局部的key，本地的綁定將會覆蓋CrossContext的那一個。
到這里所有的文檔內容已經結束了。自己着手做幾個小栗子能快速的了解和適應這樣的架構。架構的學習 確實可以改變人的編碼習慣 。 就這幾天對文檔的閱讀，感覺收獲良多 。 希望有學習的小伙伴能夠一起交流交流。