先大体介绍下我的理解的数据驱动（有些观点来之于网上）：
一套乐高积木，里面除了那些固定的方块外，还有许多其余的配件，好比齿轮、传动轴、轮胎、螺旋桨、传动带甚至电动机和开关、灯泡，那么就能够用这些配件，搭建出很不错的玩具飞机、汽车、甚至是机器人。这些乐高的配件，就是所谓的“组件”，搭建一个机械玩具所用到的方案，就是“数据”。你能够不去修改这些配件，仅仅是拼装，就是“数据驱动”编程。
回到编程领域，所谓的组件，必定是要本身自己具有必定功能的，而且和其余组件要有能配合的接口。而这一切，都须要组件自己具有完备的代码封装性，因此数据驱动中的组件，自己也是要编码实现的。然而，咱们针对性去作的组件，只能解决某些特定的问题，必定会存在范围之外的需求，因此咱们只能追加开发新类型的组件。因此数据驱动编程自己并不复杂，关键是要实现这种活动，背后要对需求领域有深入理解和模型抽象的能力。能不能作出一套你的业务领域的乐高配件，正是你在业务领域和编程技巧上的能力体现。
回到unity，GameObject Compnent就是组件，配表、图像、声音等等asset就是数据。组件是代码驱动，整个游戏是数据驱动，换句话说是数据驱动代码。为了方便数据驱动，更好的管理组件，那第一步，就是要限制代码与对象的关系。 世界中的任何单体对象，都不该该拥有改变世界（游戏逻辑）的能力。它惟一能作的，就是操做它本身，同时，若是赶上了本身能力之外的事情，必需要向管理器报告。因此，为了实现数据驱动，咱们的游戏大概有如下几种东西：
一、一个逻辑管理器，它决定了整个世界是如何运转，不一样对象之间如何交互
二、事件管理器，它负责接收来自各个对象的报靠，好比（啊，有人踩到我了；咦，这是一个传送点耶；哎哟，你为何点我。） 事件管理器起到事件队列缓存的做用，同时，游戏逻辑应该定时处理这些事件。 固然，这个事件管理器，也是逻辑管理器的一个小弟，若是逻辑管理器以为不怕麻烦，也能够亲自操刀，负责事件收集。
三、若干对象相关的脚本，用于决定对象能力。 这些脚本不作别的，只作它们本身目标对象相关的事情。 好比，控制一个对象的动画切换，检查敌人是否进入攻击范围等等。 这些脚本，是作为脚本的一种能力挂上去的。当相应事件触发时，他们会将事件通知给事件管理器。 理论上，咱们是能够彻底避免这样作的， 就像早期的引擎中，对象只是资源，逻辑代码用来操做这些资源。 可是，既然U3D提供了如此便利的东西，咱们为什么不用呢。 由于有许多事件的检测，U3D已经为咱们作好了，而且，也只有挂接在此对象上的脚本，才可以监听到这些事件，好比OnTriggerEnter。