如何组织 Rails 应用程序
我第一次创建一个相当复杂的 Rails 应用程序。
我想知道按文件夹组织该应用程序的最佳方式是什么。到目前为止，我会在一个应用程序下完成所有操作（所有模型、控制器等），但阅读一些开源代码后，我意识到他们将所有内容都放在不同的应用程序下。
例如 Spree Commerce。他们有一个通用文件夹，里面有不同的应用程序（API、核心、管理等）。这是如何完成的？这是最好的方法吗？
我希望有人指出做到这一点的最佳方法（一本书，博客，任何东西），这样我就可以了解如何构建我的应用程序以供将来维护。
谢谢
For the first time I'm creating a quite complex Rails app.
I'd like to know what's the best way to organize that app by folders. Until now, I'd do everything under one app (all the models, controllers, etC) but reading some open source code I realize that they put everything under different apps.
Like for example Spree Commerce. They have a general folder and inside that they have different apps (API, core, admin, etc). How is that done and is that the best way to do it?
I'd like to get pointed to the best way to do it (a book, blog, anything) so I can understand how I can architect my app for future maintenance.
thank you
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
顺便说一句，我认为你的问题的标题有点令人困惑。 Rails 通过使用约定优于配置，定义了“如何组织 Rails 应用程序”。我认为您的问题是如何构建您的应用程序，而不是任何 Rails 特定的问题。也许可以调整一下标题？
除此之外，在不了解有关您的项目的更多细节的情况下，这是一个很难回答的问题，但我会尝试一下。
所有应用程序都应该从简单开始，如果您相信（像我一样）应该从构建 最简单的东西开始这可能会起作用。鉴于此，由于您使用的是 Rails，那么最简单的事情很可能是将您的应用程序构造为普通 Rails 3 应用程序。这可能（我说“可能”是因为我不知道该应用程序的任何细节）允许您快速启动并运行应用程序的测试版，而不必担心项目开发现阶段的复杂性都不是问题。
如果您需要创建基于 XML 或 JSON 的 API，则 Rails 会创建 使用标准框架非常简单，这将让您花更多时间思考 API 设计，而不是如何编码，而这就是 API设计是首先要做好的最重要的事情。
同样，您的管理站点可以是同一应用程序的一部分，只是位于不同的命名空间中。如果您稍后发现您希望将其作为一个单独的应用程序，您可以这样做（也许您可以使用您设计的出色的 API 来促进这一点），但是为什么要费心设计这种增加的复杂性（并因此延长开发时间） ）首先，如果您没有充分的理由这样做？
一旦你的应用程序启动并运行并且人们开始使用它，你就开始了解瓶颈在哪里以及设计可以改进的地方。在此阶段，如果有需要，您可以开始将应用程序的部分内容迁移到可扩展的解决方案，例如将 API 作为独立服务运行、引入缓存、更改数据存储以及其他改进和优化。
即使您的应用程序非常成功（我希望如此！），那么在继续运行现有服务的同时重新构建您的应用程序仍然是完全可能的，正如 Twitter 所证明的那样。只要坚持Knuth 的声明，你就会没事的。
关于阅读材料，这是一个棘手的问题。对我来说，许多 XP 和敏捷开发经典教会了我很多关于如何进行程序和应用程序设计的知识。我还会检查这个 StackOverflow 主题< /a> 获取书籍灵感。
祝你好运！
As an aside I think the title of your question is a little confusing. Rails, by using convention over configuration, defines 'how to organise a Rails app'. I think your question is rather about how to architect your application as opposed to anything Rails-specific. Maybe tweak the title?
That aside, without knowing any more detail about your project it's a tricky question to answer, but I'll give it a go.
All applications should start off simple, if you believe (like I do) that you should start by building the simplest thing that could possibly work. Given this, since you're using Rails, then in all likelihood the simplest thing would be to structure your app as a vanilla Rails 3 application. This will probably (I say 'probably' because I don't know any specifics about the app) allow you to get a beta version of your app up and running pretty quickly without worrying about complexities which at this stage in the development of your project are not a problem.
If you need to create an XML or JSON-based API then Rails makes this really easy using the standard framework, which will allow you to spend more time thinking about the API design than how to code it, and it's the API design which is the most important thing to get right in the first instance.
Similarly, your Admin site can be part of the same app just in a different namespace. If you find later down the line that you want it as a separate app, you can do this (maybe you could use the awesome API you designed to facilitate this), but why bother designing it with this added complexity (and hence extended development time) in the first place if you don't have a good reason for doing so?
Once you have your app up and running and people are starting to use it, you start to get a picture of where the bottlenecks are and where the design could be improved. At this stage, if there's a need, you can start to move parts of the app to scalable solutions, such as running your API as a standalone service, introducing caching, changing data stores and other improvements and optimisations.
Even if your app is as wildly successful (and I hope it is!) then re-architecting your application whist continuing to run the existing service is still entirely possible, as Twitter have proved. Just stick to Knuth's statement and you'll be alright.
Regarding reading material, that's a tricky one. For me a lot of the XP and agile development classics taught me a huge amount about how to approach program and app design. I'd also check this StackOverflow topic for book inspiration.
Good luck!
Spree 使用 Rails 的 Railties (Rails::Engines）。 Railties 在 Rails 3 中引入，使其更加模块化且易于扩展。 Rails 3 本身是 Railties（ActiveSupport、ActiveModel、ActiveRecord 等）的集合。
如果您正在开发一个复杂的应用程序，我建议您花一些时间规划其架构。在没有任何初始规划的情况下设计一个复杂的应用程序肯定会以维护噩梦告终。它还为新团队成员引入了巨大的学习曲线，减慢了新功能的引入速度，当然还有挫败感。
无论如何，不要过度优化，但不要忘记根据您的需求设计架构。
Spree uses Rails' Railties (Rails::Engines). Railties are introduced in Rails 3 to make it more modular and easy to extend. Rails 3 itself is a collection of Railties (ActiveSupport, ActiveModel, ActiveRecord, etc.).
If you are developing a complex app I would suggest spending some time planing its' architecture. Designing a complex app without any initial planning would definitely end with a maintenance nightmare down the road. It also introduces a huge learning curve for the new team members, slow down your new feature introduction and of course, frustration.
Anyway, don't over optimize, but don't forget to design your architecture for your needs.
恕我直言，我将创建非常复杂的项目作为一个应用程序。我有理由相信 Spree 和 Radiant 是在单独的应用程序下构建的，因此在其开源社区的幌子下，贡献者可以轻松地贡献代码，而无需篡改核心数据和应用程序的核心工作。
否则，您只需将其构建为一个应用程序就可以了。只要保持整洁即可。
IMHO, I will create very complex projects as one app. I have reason to believe that Spree and Radiant build under seperate apps so that under the pretense of their open source communities, contributors can contribute code easily without tampering with the core data, and the core workings of the application.
Otherwise, you should be alright just building it as one app. Just keep it neat.
以下是让我在几年的 RoR 开发中保持理智的原因：
我使用 Rails 引擎，但将它们保留在与主应用程序相同的代码库中。这是模块化 Rails 应用程序的良好入门：
https://github.com/shageman/the_next_big_thing
只要可以，我都会尝试减少耦合，使用组合使事物易于测试、可重用和可维护。这有助于最终将模块或引擎提取为单独的 gem。组合是通过路由（挂载）、目录覆盖（资产）、依赖项注入或配置来完成的。
如果我不需要重复使用引擎，我会将其放在与主应用程序相同的代码库中，这是单个部署单元。因此，我不需要在 IDE 中的项目之间切换。在开发环境中，对引擎代码的任何更改都会立即被 Rails 重新加载机制接收。
Here is what have kept me sane for several years of RoR development:
I use Rails Engines, but keep them in same codebase as the main app. Here is good starter for modular Rails app:
https://github.com/shageman/the_next_big_thing
Wherever I can I try to reduce coupling and use composition to make things easily testable, reusable and maintainable. This helps to eventually extract module or engine as separate gem. Composition is done by routes (mounting), directory overlaying (assets), dependency injection or configuration.
If I don't need to re-use an engine I put it in the same code base as the main app which is single deployment unit. Thanks to that I don't need to switch between projects in my IDE. While in development environment any changes to the engine code are instantly picked up by Rails reload mechanism.