pureMVC与strangeIoc框架对比

前言

最近有机会了解到了StrangeIoc框架，就拿来跟自己比较熟悉的pureMVC进行一下简要的对比。这两套开源框架都是基于MVC模式的扩展，pureMVC是一个跨平台跨语言的MVC轻量级应用框架，它最早是应用在flash开发中，后来经过不断的发展，现已支持几乎所有的平台，当然在unity开发中应用也很广泛；StrangeIoc是一款基于MVCS的框架，专门C#和Unity而设计，可以直接在Asset Store下载。

pureMVC介绍

pureMVC框架示意图

 

在MVC模式中，应用程序被分为低耦合的三层：Model、View和Controller。PureMVC在此基础上有所扩充，通过模块化设计，可以进一步降低模块间的耦合度，创建了一个易于扩展限制很小的通用框架。

 

PureMVC源码分析

 

1、核心层中是三个单例类：

Model：保存对Proxy对象的引用，Proxy负责操作数据类型

View：保存对Mediator对象的引用，Mediator负责操作具体的视图组件

Controller：保存所有Command的映射，Command执行相关命令。

在实际开发中，你根本不需要关心这三个类，只需调用Facade类的GetInstance方法即可启动pureMVC框架，Facade会自动帮你初始化MVC环境。

 

2、框架内部通讯：

pureMVC内部通讯是基于Observer/Notification 机制(观察者模式)来实现的，只需要使用一个非常简单的方法从 Proxy,Mediator, Command 和 Facade 发送 Notification。

 

3、Facade：

这是pureMVC提供的与核心层通讯的单例类，它负责初始化Model、View、Controller，Proxy、Mediator 和 Command 就可以通过创建的 Facade 类建立起通信机制。

 

4、Mediator

Mediator(中介) 对应MVC中的View.，在实际应用中，Mediator经常与view是绑定的关系， Mediator可以监听View Component发出的Event,开发时，在ListNotificationInterests方法中添加自己关心的Notification， 当关心的Notification发出时， 会执行Mediator的HandleNotification方法中，在这个方法中需要对Notification做处理。Mediator既可以发送通知，也可接收通知。

 

5、Proxy

Proxy通常情况下会暴露一组公共API供Controller(command)或View(mediator)调用，用来对数据进行增删改查。在pureMVC的设计中，proxy只可以发出Notification，而不能接收Notification

 

6、Command

command与Notification是一一对应的，注册Command时，会将Notification与对应Command进行绑定，当该Notification发出时，对应command就会执行它的Excute方法。puremvc中有两种Command：第一种是SimpleCommand ，只有一个 execute 方法，execute 方法参数是一个Inotification 实例。实际应用中，你只需要重写这个方法就行了。第二种是MacroCommand，让你可以顺序执行多个 Command。实际应用中，你需重写这个方法。

 

pureMVC特点：

1、pureMVC巧用了几种设计模式：代理模式 、观察者模式 、中介者模式 、命令模式 、单例模式 。

2、使Model、View、Controller之间耦合降低，但也容易造成了代码冗余量大。

3、pureMVC将Observer/Notification保存在字典中，Notification的传递也都要经过装箱拆箱操作，如果在大型项目中使用pureMVC可能会影响性能。

 

StrangeIoc介绍

框架简介

StrangeIoc 是一个基于MVCS的框架，支持依赖注入。网上很多博文都说strangeIoc是一个依赖注入框架，其实这种说法是不够正确的，这个框架的核心，是绑定。strangeIoc的核心内容就是对绑定进行了包装，可以绑定一个接口到它的实体类上面。或者绑定一个事件到一个处理者上。或者绑定两个类：当一个被实例化时，自动创建另一个的实例。

IOC也被成为控制反转，在StrangeIOC与许多框架通常用这种技巧实现一个ioc容器，将代码内的依赖关系交给第三方(IOC容器)管理，通过容器来实现对象组件的装配和管理。所谓的“控制反转”概念就是对组件对象控制权的转移，从程序代码本身转移到了内部的容器。需要什么类型告诉工厂你要的类型，他会生产给你一个实例，简而言之我们可以看作是一个用来new类型的工厂 。

 

starngeIoc框架示意图

Root(contexView)：根节点，继承自MonoBehavior ，创建一个MVCS Context，是MVCS架构的入口。

 

MVCS Context  ：进行view与mediator，services接口与实现该接口的类的绑定等。

 

CONTROLLER：大部分逻辑处理放在这一层，连接VIEW和SERVICES,MODELS层，起到数据总管理的作用。

 

VIEW：一切用户可以看到的，均在这一层。细分为view和mediator(中间层)，UI和数据分离，view负责显示画面，mediator通过Dispatcher发送数据请求，与CONTROLLER层进行交互，起到数据交流中转站的作用。

 

SERVICES层：服务层，客户端的数据通过SERVICES层与外界交互，连接服务器取得数据。基本上与服务器的数据交流均通过SERVICES层完成。

 

WEB：服务器

 

MODEL：数据模型

 

绑定（Binding）

strange的核心是绑定，绑定的工作都会放在MVCSContext中做， strange的binding由两个必要部分和一个可选部分组成，必要部分是a key and a value  key触发value，比如一个事件可以触发回调，一个类的实例化可以触发另一个类的实例化。可选部分是name。

绑定可以分为injectionbinding  ,commandbinding,mediationbing这三种，注入绑injectionbinding主要是用来绑定该类型对象到上下文，这样使得程序中各个地方可以通过contextview访问得到该对象；commandbinding是为了将事件或信号与命令绑定；mediationbing是将view注入中介mediator中。

 

 

注入（Inject）

注入的功能，就是我们想获得某种类型的对象时不需要自己去创建，只要加上[Inject]标识就可以根据你bind时的规则获得对象，根据这些Inject标识，框架会找到这些属性，通过类型判断按Context中注册的规则将对象的实例赋值给该属性。

 

框架内部通讯

StrangeIOC提供的通讯方式有两种 ：一种是IEvent传递，还有一种是通过Signal传递，这两种方式，我们实际开发时使用一种即可，使用IEvent的好处是自己可以继承此接口自己实现自定义的消息体，缺点是每次接收到消息的时候都是以IEvent接口的形式，这是一种类型不安全的做法，同时也会造成不必要的性能损耗。Signal是StrangeIOC框架成熟后提供的，Signal的好处是强类型 ，类型安全也不需要强转，你只需要在接收的地方Inject属性即可，目前，大家开发时都使用signal的方式比较多。

 

总结

pureMVC与strangeIoc都是非常适合unity项目开发，pureMVC框架足够简单，源码除去注释行总共才600多行，看懂源码也不是什么难事，有兴趣的朋友可以去下载研究 https://github.com/PureMVC/puremvc-csharp-standard-framework ，在实际开发中，我们通常也会对pureMVC框架进行扩展，比如加入Service模块，负责与服务器通讯，这也是很方便能实现，同时，针对pureMVC的性能问题，网上也能找到一些优化的方案，pureMVC可扩展性是很强的。strangeIoc框架上手会比strangeIoc困难一些，就像它的名字一样，使用起来确实很奇怪，项目开发中会涉及各种事件和信号调用，调试起来会比较麻烦。框架的作者介绍这是一款轻量级的框架，但这框架的源码有两万多行，这可不算轻量，我看了几眼框架的源码就脑阔痛，但不可否认它确实是一款优秀的框架，通过依赖注入，event&signal传递的方式，大大降低模块之间的耦合，使用起来也很灵活，据我所知腾讯有很多上线项目都用到了这个框架，地址https://github.com/strangeioc/strange-core 。至于在开发时使用哪个框架比较好，这还得看实际情况，但显然pureMVC使用起来成本更低。