今天如果是要开发一个在移动平台上的应用程序，应用程序的功能要够丰富，就势必得牵涉到数据存取的议题。否则用户在操作程序时，就如同和海底总动员的 Dory 对话一般，每次开启程序都只能反覆地进行基本的作业、无法累积操作状态的信息。

然而数据要怎么存，其实会受到程序的需求、使用情境、营运预算等等因素的影响。所以选择合适的数据存取方案是开发过程中很重要的考量，常见移动设备的数据存取选项有以下几种：

• Local
• Client-Server
• Master-To-Master
• Peer-To-Peer

Local

将数据留在程序运行的设备之上，这是最基本的数据存取模式，也是最直接、成本最低的一个选项。二大主要的移动平台都有在 SDK 中提供对应的功能，开发人员只要依照规格撰写程序即可达到效果。这个选项的最大限制就是没有办法体现移动平台的移动特性，应用程序处于孤岛的状态，以致程序在跨装置的使用上还是有很大的局限性。

Client-Server

将数据留在远端的服务器的选项，这原本就是在 Web 平台上必备的一种方案，由于在浏览器上运作的程序无法直接读写磁碟机，所有的数据写入与呈现都要靠与远端的服务器互动来提供。不管是要直接登入后端的数据库来存取数据，还是要透过中介的应用层以 REST 方式传递 XML 或 JSON 格式的数据，在技术层面上来说都不是很高的门槛。很多的第三方函式库都已经大幅地简化了这部份程序码的复杂度，开发人员只要把精力投注在数据处理的逻辑上。

这个方案也解决了 Local 选项的缺点，可以在跨装置的使用情境之下编辑同一份数据，增加使用的弹性。但缺点是建置伺器需要支出额外成本，就算是使用云服务，不论是 CPU、储存空间、还是网络流量，都是要按使用等级定期收费。所以盈收没有到一定的程度，在营运上会产生很大的负担。在开发上，由于数据全部都是透过网络的传递，如何在数据传递的过程中保护数据、如何避免远端的服务器遭到入侵是要很审慎地应对，否则可能会因为数据外泄所引起的消费纠纷造成额外的营运损失。在使用上则会因为数据都在远端，一但网络失去连线就有可能会终止程序的运作，阻碍程序的使用经验。

Master-To-Master

毕竟移动平台的应用程序有一个比 Web 平台还具优势的特点是可以直接存取磁碟机，所以融合了前二个方案的优点就是分别在前、后端都设置一个数据储存的机制，透过同步的方式让本地端与服务器端的数据保持一致。如此一来，当前端网络失去连线时，仍然在设备上保有一份数据可以维持程序的运作。而远端所储存的数据则可以用来提供在跨设备的情境之下交换数据，达到 Client-Server 方案的便利性。

目前这个选项已经有第三方的框架辅助简化程序开发的成本，像是：CouchDB 、CouchBase Lite、PouchDB。不过，严格来说 PouchDB 应该算是网络不稳时的解决方案，而不是真正的离线使用。

这个架构的缺点除了和 Client-Server 一样需在后端建置服务器所可能产生的问题之外，在开发上会出现的是同步规则的处理，因为是多点同时读写数据，又混和了在线与离线的情境，所以很容易出现数据冲突的情况。要如何妥善的处理数据冲突，又不致会让用户不信任程序的处理模式，是一个需要投入心力思考的关键点。

Peer-To-Peer

如果以上的选项都没有办法满足程序的需求，但又想要可以跨装置来编辑同一份数据，那还可以有一种选择是让装置进行点对点的同步。如果没有第三方库的搭配，就要自行选写发送与聆听网络讯息的程序，须具有足够的网络通讯知识才有办法完成任务。除此之外，还是要自行解决数据交换后的同步与冲突解决的问题。

在缺点上，少了服务器，当然就不会有建置服务器所可能产生的问题。但相对地，要付出的开发成本就会提高，至于提到多高就要看对后续营运的品质要求有多少。毕竟这个选项很有可能要自行由网络通讯的中下层开始，重新打造一个轮子，要做到市面上成熟产品的验证强度来达到相对的稳定度，就成本来看会很可观。如果只是个简单的小应用，就不用大费周章地做这种吃力不讨好的选择。