移动应用 - 服务器架构

Question

我想开始一个移动应用程序，但我有一些问题。我对数据库连接层感到困惑。我应该构建我的架构2层;第一层是移动应用程序（在移动应用程序中建立数据库连接），第二层是数据库。或3层;第一个是移动应用程序，第二个是服务器（处理数据库和应用程序之间的连接），第三个是数据库。

这两种架构的优点和缺点是什么？ 提前致谢

Answer 1

让移动应用直接与数据库通信的唯一好处是，在短期内实施可能会更快。

在稍长的时间内，由于以下几个原因，三层是更好的选择：

1. 灵活性 - 让移动应用程序针对提取数据库内部的服务层（例如，通过一些JSON API）工作。这样可以更轻松地更改架构，甚至可以替换整个数据层，而不会破坏移动客户端。当您发布涉及移动应用程序和数据层更改的新版本，以及尚未更新的某些应用程序时，这一点至关重要。服务层将支持多个版本的可管理性。直接使用数据库将使其几乎不可能。

2. 安全性 - 管理用户登录，权限等通常不像在服务层中那样受支持。

3. 可扩展性 - 如果您的应用成功并且您需要扩展服务器端，服务层将大大增加您的选择（回到第1 - 灵活性）。

4. 这应该足以让你相信，但我相信其他回复会提出更多：）

关于您的其他问题 - 为服务器推荐技术/架构，有许多可行的选项 - Ruby，Python，PHP，Node。 “最好”取决于你已经熟悉的东西。

Answer 2

在您描述的第一个案例中，您谈论的是移动设备的本地数据库。根据您的移动应用程序的要求，这可能就足够了。一个简单的案例：仅限移动设备的“TODO”应用程序。输入此类应用程序的所有条目只能在同一个应用程序中读取，并且不会同步到中央服务器（云）。

让我们说“TODO”一夜成名，您希望发布“TODO 2.0”，能够在不同媒体之间同步“待办事项”列表：网站，桌面应用和移动设备。您将不得不在此图片中引入一个服务器，该服务器将存储“TODO”数据库并便于访问它。您的移动应用程序可以在从服务器读取它们时创建“todo”项目的内存列表，或者它可能仍然将本地数据库作为简单缓存。