一个大的Rails应用程序与单独的应用程序

Question

我正在开展一个大项目。现在我们需要添加新功能：scheduler管理。 它不是应用程序的主要任务，但它是相当复杂的部分。

将其作为单独的应用程序提取是否是个好主意？

它将共享一些数据（用户和其他一些个性），它将使用相同的数据库。

我想要做的主要原因是简化主要应用程序。

我明白，这可能是一个太宽泛的问题。但也许您可以分享您开发此类应用程序的经验，也许我可以阅读任何文章和世界范围内的最佳实践。

Answer 1

虽然其他人已经提到了分离应用程序的一些好处，但我会谈到为什么你不想分开代码的几个原因。

1. 您将需要维护一组测试，特别是如果两个应用程序共享同一个数据库。如果你不这样做，很难预测何时更改一个应用程序会破坏另一个应用程序，特别是如果应用程序开始需要从数据库中获取不同的东西。
2. 这两个应用程序显然会有很多重叠（例如用户）。分成两个应用程序可能会强制您重复代码，因为默认情况下rails有一些关于如何构建rails应用程序的非常具体的想法。例如，如果您的应用程序正在共享某些视图，那么当一个应用程序想要修改视图时，您将如何协调两个应用程序中的更改？

这些都不是不可克服的，但是当你遵循rails约定时，rails是最容易开发的。当你开始偏离时，你最终不得不做更多的工作。此外，不要将这些要点中的任何一个视为使其他答案无效，而只是将你需要考虑的对应点。

Answer 2

当您也可以在其他项目中使用该功能时，我会将其分开。 也许您可以创建一个rails引擎，以便在项目之间轻松共享。

Answer 3

考虑问自己“可重用性怎么样？”新的调度功能是否可以在另一个应用程序的另一个上下文中重用？如果答案是“是”，那么可能使调度管理在设计上更加模块化将为您节省时间。如果答案是“否”，那么我认为您在调度管理与现有应用程序的紧密程度方面有更多的余地。

这里的实际区别在于编写通用调度管理功能，该功能具有可分配的表和方法，而不是使用“onebig项目”的数据/代码方案对其进行“硬编码”。

hth -

佩里

Answer 4

根据我的经验，将管理工具添加到Web应用程序中通常会使部署变得复杂。特别是当您的应用程序的使用增长，并且您需要对其进行性能调整时，拖动巨大的“后端”可能会有问题。

为了部署，扩展和测试能力，我更喜欢我的应用程序小而专注。有时甚至还可以通过REST-XML服务获得整个管理环境。

但正如其他答案所指出的：这更像是一种“依赖”的解决方案。这些是我的0.02欧元。