我正在使用 Rails 开发一个管理 Web 应用程序。由于各种实施细节并不真正相关，支持此应用程序的数据库将拥有支持另一个单独网站所需的所有内容。似乎有两个明显的选择：
我的问题是：这些选项中的任何一个都可行吗？如果是这样，它们中的哪一个似乎是更好的选择？ Rails、Sinatra 或任何其他基于 Rack 的 Web 框架是否特别适合此类项目？ （我倾向于 Sinatra，因为它似乎比 Rails 更轻量级，而且我认为我的 Rails 经验会很好地延续到它。）
谢谢！
【问题讨论】：
标签： ruby-on-rails database web-applications sinatra
这两个都是可行的，我过去都使用过，但我会使用 API 方法。
快速免责声明：尚不清楚的一件事是这些应用在功能上有何不同。例如，我可以想象旧的应用程序是处理单个记录的 CRUD 应用程序，而新的应用程序是执行大型复杂聚合查询的报告应用程序。这使得共享数据库（也许）更具吸引力，因为您访问数据的方式重叠非常小。我假设下面的情况不是。
无论如何，API 方法。首先，不好的：
但另一方面，好的：
对架构更改更具弹性。您的“旧”应用程序的 API 可以进行测试，并且您可以随心所欲地使用数据库（在旧应用程序的上下文中），并保持您的 API 符合其规范。您的新应用程序不会知道其中的区别，这很好。抽象 FTW。这是“多一个依赖”硬币的反面。
同一点，但角度不同：在我们共享数据库的方法中，您的架构 + 所有 SQL 实际上就是您的 API，它有两个客户端，旧应用程序和新应用程序。除非您的两个应用程序使用相同的数据做非常不同的事情，否则这绝不是最好的 API。定义太差了。
数据库管理/仪器更好。假设您弄乱了一些查询并软管您的数据库。是哪个应用程序？这些查询来自哪里？基本上，可以与数据库交互的东西越少越好。相关：在一处优化您的读取查询，而不是两处。
如果您在现有应用程序中使用 RESTful 路由来执行非 API 操作，我猜您的 API 需求将与您现有的控制器代码有很大的重叠。这可能只是将您的数据转换为 JSON 而不是将其传递给视图的问题。 Rails 使得使用动作来响应 API 和用户驱动的请求变得非常容易。因此，如果适用的话，这将是一个巨大的 DRY 胜利。
如果您发现自己确实希望新应用具有可写性怎么办？或者至少可以访问您的旧应用程序不关心的某些字段（也许您使用脚本添加了它）？在共享数据库方法中，这很糟糕。另一个，只是稍微扩展 API 的问题。
基本上，我采用共享数据库方法的唯一方法是我讨厌旧代码并想重新开始。这是可以理解的（我也确实这样做了），但这并不是架构上最合理的选择。
要考虑的第三个选项是在两个应用程序之间共享代码。例如，您可以生成模型代码。现在，您的 API 实际上是一些知道如何与数据库对话的 Ruby 类。更进一步，您可以编写一个 Sinatra 应用程序并将其安装在现有的 Rails 应用程序中并重用它的大部分。然后只需制定路由，使它们看起来像外部世界的独立应用程序。这是否实用显然取决于您的具体情况。
就具体技术而言，Sinatra 和 Rails 都是不错的选择。我倾向于 Rails 用于较大的项目，而 Sinatra 则用于较小的项目，但这只是我。做感觉好的事。
【讨论】：