移动应用程序-服务器架构
我想启动一个移动应用程序，但我有一些问题。我对数据库连接层感到困惑。我应该构建 2 层架构吗？第一层是移动应用程序（在移动应用程序中进行数据库连接），第二层只是数据库。或3层；第一个是移动应用程序，第二个是服务器（处理数据库和应用程序之间的连接），第三个是数据库。
这两种架构各有什么优缺点？ 提前致谢
I want to start a mobile application however I got some questions. I am confused about database connection layer. Should I construct my architecture 2 layered; 1st layer is mobile app (making the database connection in mobile app), 2nd layer is just database. Or 3 layered; 1st is mobile app, 2nd is server (which handles the connection between database and app), 3rd is database.
What are the pros and cons of these two architecture?
Thanks in advance
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
让移动应用程序直接与数据库通信的唯一优点是，短期内实施起来可能会更快。
从长远来看，三层是更好的选择，原因如下：
灵活性 - 让移动应用程序针对抽象数据库内部结构的服务层（例如，通过一些 JSON API）工作。这将使更改架构变得更加容易，甚至替换整个数据层，而不会破坏移动客户端。当您发布的新版本涉及对移动应用程序和数据层的更改，并且有一些应用程序尚未更新时，这一点至关重要。服务层将使对多个版本的支持变得易于管理。直接使用数据库几乎是不可能的。
安全性 - 管理用户登录、权限等在数据库中通常不像在服务层中那样得到很好的支持。
可扩展性 - 如果您的应用程序成功并且您需要扩展服务器端，服务层将大大增加您的选择（回到第一 - 灵活性）。
这应该足以让你相信，但我相信其他回复会提出更多:)
关于您的其他问题 - 推荐服务器的技术/架构，有很多可行的选择 - Ruby、Python、PHP、Node。 “最好的”取决于您已经熟悉的内容。
The only advantage of having the mobile app communicated directly with the database is that it might be faster to implement in the short run.
In the slightly longer run, three layers are a much better choice for several reasons:
Flexibility - have the mobile app work against a service layer (for example, through some JSON APIs) that abstracts the database internals. This will make it much easier to make changes to your schema, even replace the entire data layer, without breaking the mobile clients. This is critical when you release new versions that involve changes to both your mobile app and your data layer, and have some apps out in the field that didn't update yet. A service layer will make support for multiple versions manageable. Working directly with the database would make it very nearly impossible.
Security - managing user logins, permissions etc. is usually not as well supported in the DB as it is in a service layer.
Scalability - should your app succeed and you'll need to scale the server side, a service layer would greatly increase your options (going back to no. 1 - flexibility).
This should be enough to get you convinced, but I'm sure other replies will come up with more :)
Regarding your other questions - recommend a technology/architecture for the server, there are lots of viable options - Ruby, Python, PHP, Node. The "best" depends on what you're already familiar with.
在您描述的第一种情况下，您讨论的是移动设备的本地数据库。根据您的移动应用程序的要求，这可能就足够了。一个简单的案例：仅限移动设备的“TODO”应用程序。输入此类应用程序的所有条目只能从同一应用程序内读取，并且它们不会同步到中央服务器（云）。
假设“TODO”一夜成名，您希望发布“TODO 2.0”，能够在不同媒介（网站、桌面应用程序和移动设备）之间同步“待办事项”列表。您必须在此图中引入一个服务器来存储“TODO”数据库并方便对其进行访问。您的移动应用程序可以在从服务器读取“待办事项”项目时在内存中创建列表，或者它可能仍然将本地数据库作为简单的缓存。
In the first case you described, you're talking about a local database for a mobile device. Depending on requirements for your mobile app this could be sufficient. A simple case: a mobile-only "TODO" application. All the entries entered into such app can only be read from within the same app and they don't get synched to a central server (cloud).
Let's say "TODO" became on overnight success and you want to release "TODO 2.0" with an ability to sync 'todo' lists between different mediums: a web site, a desktop app and a mobile device. You will have to introduce a server in this picture that would store "TODO" database and facilitate an access to it. Your mobile app can create in-memory list of 'todo' items as it reads them form the server, OR it might still have the local database as a simple cache.