For the first time I'm creating a quite complex Rails app.
这是我第一次创建一个非常复杂的Rails应用程序。
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.
我想知道按文件夹组织该应用程序的最佳方法是什么。到现在为止，我会在一个应用程序（所有模型，控制器，etC）下做所有事情但是阅读一些开源代码我意识到他们把所有东西放在不同的应用程序下。
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?
例如Spree Commerce。他们有一个通用文件夹，里面有不同的应用程序（API，核心，管理员等）。这是怎么做的，这是最好的方法吗？
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
谢谢
4 个解决方案
#1
7
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?
另外，我认为你的问题的标题有点令人困惑。 Rails通过使用约定优于配置来定义“如何组织Rails应用程序”。我认为你的问题是关于如何构建应用程序而不是Rails特定的任何东西。也许调整标题？
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.
所有应用程序应该从简单开始，如果你相信（像我一样）你应该从构建可能有效的最简单的东西开始。鉴于此，由于您使用的是Rails，因此最简单的方法是将您的应用程序构建为vanilla Rails 3应用程序。这可能（我说'可能'，因为我不知道有关该应用程序的任何细节）允许您快速获得应用程序的测试版并运行，而不必担心在项目开发的这个阶段的复杂性不是问题。
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.
如果你需要创建一个基于XML或JSON的API，那么Rails使用标准框架可以很容易地实现这一点，这样你就可以花更多的时间来考虑API设计，而不是如何对它进行编码，这就是API设计，即最重要的是要在第一时间做到正确。
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?
同样，您的管理站点也可以位于不同命名空间中的同一个应用程序中。如果你在以后找到你希望它作为一个单独的应用程序的行，你可以这样做（也许你可以使用你设计的那个很棒的API来促进这个），但为什么要用这个增加的复杂性来设计它（因此延长了开发时间） ）首先，如果你没有充分的理由这样做？
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.
一旦您的应用程序启动并运行并且人们开始使用它，您就可以开始了解瓶颈所在的位置以及可以改进设计的位置。在此阶段，如果有需要，您可以开始将应用程序的各个部分移动到可扩展的解决方案，例如将API作为独立服务运行，引入缓存，更改数据存储以及其他改进和优化。
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.
即使您的应用程序非常成功（我希望它是！），然后重新设计您的应用程序惠斯特继续运行现有服务仍然是完全可能的，正如Twitter已经证明的那样。只要坚持Knuth的陈述，你就会好起来的。
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 * topic for book inspiration.
关于阅读材料，这是一个棘手的问题。对我来说，很多XP和敏捷开发经典教会了我很多关于如何处理程序和应用程序设计的知识。我还要查看这个*主题以获取图书灵感。
Good luck!
祝你好运！
#2
6
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.).
Spree使用Rails的Railties（Rails :: Engines）。 Rails 3中引入了铁轨，使其更加模块化，易于扩展。 Rails 3本身是Railties（ActiveSupport，ActiveModel，ActiveRecord等）的集合。
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.
无论如何，不要过度优化，但不要忘记根据您的需求设计您的架构。
#3
2
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.
恕我直言，我将创建非常复杂的项目作为一个应用程序。我有理由相信Spree和Radiant在单独的应用程序下构建，因此在他们的开源社区的借口下，贡献者可以轻松地贡献代码，而不会篡改核心数据和应用程序的核心工作。
Otherwise, you should be alright just building it as one app. Just keep it neat.
否则，您应该将其构建为一个应用程序。保持整洁。
#4
0
Here is what have kept me sane for several years of RoR development:
这是RoR开发多年来让我保持理智的原因：
-
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
我使用Rails引擎，但将它们保存在与主应用程序相同的代码库中。这是模块化Rails应用程序的良好入门者：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.
无论我在哪里，我都可以尝试减少耦合并使用成分来使事情易于测试，可重复使用和可维护。这有助于最终将模块或引擎提取为单独的gem。通过路由（安装），目录覆盖（资产），依赖注入或配置来完成组合。
-
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.
如果我不需要重新使用引擎，我将它放在与主要应用程序相同的代码库中，即单个部署单元。多亏了我不需要在我的IDE中切换项目。在开发环境中，Rails重载机制会立即获取对引擎代码的任何更改。
#1
7
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?
另外，我认为你的问题的标题有点令人困惑。 Rails通过使用约定优于配置来定义“如何组织Rails应用程序”。我认为你的问题是关于如何构建应用程序而不是Rails特定的任何东西。也许调整标题？
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.
所有应用程序应该从简单开始，如果你相信（像我一样）你应该从构建可能有效的最简单的东西开始。鉴于此，由于您使用的是Rails，因此最简单的方法是将您的应用程序构建为vanilla Rails 3应用程序。这可能（我说'可能'，因为我不知道有关该应用程序的任何细节）允许您快速获得应用程序的测试版并运行，而不必担心在项目开发的这个阶段的复杂性不是问题。
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.
如果你需要创建一个基于XML或JSON的API，那么Rails使用标准框架可以很容易地实现这一点，这样你就可以花更多的时间来考虑API设计，而不是如何对它进行编码，这就是API设计，即最重要的是要在第一时间做到正确。
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?
同样，您的管理站点也可以位于不同命名空间中的同一个应用程序中。如果你在以后找到你希望它作为一个单独的应用程序的行，你可以这样做（也许你可以使用你设计的那个很棒的API来促进这个），但为什么要用这个增加的复杂性来设计它（因此延长了开发时间） ）首先，如果你没有充分的理由这样做？
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.
一旦您的应用程序启动并运行并且人们开始使用它，您就可以开始了解瓶颈所在的位置以及可以改进设计的位置。在此阶段，如果有需要，您可以开始将应用程序的各个部分移动到可扩展的解决方案，例如将API作为独立服务运行，引入缓存，更改数据存储以及其他改进和优化。
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.
即使您的应用程序非常成功（我希望它是！），然后重新设计您的应用程序惠斯特继续运行现有服务仍然是完全可能的，正如Twitter已经证明的那样。只要坚持Knuth的陈述，你就会好起来的。
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 * topic for book inspiration.
关于阅读材料，这是一个棘手的问题。对我来说，很多XP和敏捷开发经典教会了我很多关于如何处理程序和应用程序设计的知识。我还要查看这个*主题以获取图书灵感。
Good luck!
祝你好运！
#2
6
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.).
Spree使用Rails的Railties（Rails :: Engines）。 Rails 3中引入了铁轨，使其更加模块化，易于扩展。 Rails 3本身是Railties（ActiveSupport，ActiveModel，ActiveRecord等）的集合。
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.
无论如何，不要过度优化，但不要忘记根据您的需求设计您的架构。
#3
2
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.
恕我直言，我将创建非常复杂的项目作为一个应用程序。我有理由相信Spree和Radiant在单独的应用程序下构建，因此在他们的开源社区的借口下，贡献者可以轻松地贡献代码，而不会篡改核心数据和应用程序的核心工作。
Otherwise, you should be alright just building it as one app. Just keep it neat.
否则，您应该将其构建为一个应用程序。保持整洁。
#4
0
Here is what have kept me sane for several years of RoR development:
这是RoR开发多年来让我保持理智的原因：
-
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
我使用Rails引擎，但将它们保存在与主应用程序相同的代码库中。这是模块化Rails应用程序的良好入门者：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.
无论我在哪里，我都可以尝试减少耦合并使用成分来使事情易于测试，可重复使用和可维护。这有助于最终将模块或引擎提取为单独的gem。通过路由（安装），目录覆盖（资产），依赖注入或配置来完成组合。
-
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.
如果我不需要重新使用引擎，我将它放在与主要应用程序相同的代码库中，即单个部署单元。多亏了我不需要在我的IDE中切换项目。在开发环境中，Rails重载机制会立即获取对引擎代码的任何更改。