多域 Rails 应用程序。如何智能地使用MVC？
背景： 我们有应用程序 a、b，并计划将更多应用程序添加到同一应用程序中。这些应用程序非常相似，可以共享许多视图、资产和操作。目前 a,b 位于单个 Rails 应用程序中 (2.3.10)。 c 将足够相似，它也可能出现在这个 Rails 应用程序中。
问题： 随着我们继续向这个应用程序添加更多应用程序，将会有太多的案例逻辑，该应用程序很快就会成为维护的噩梦。还存在潜在的命名空间问题。然而，这些应用程序在功能和布局上非常相似，将它们保留在一个应用程序中也是有意义的，这样它就成为一个需要维护的应用程序（因为大约 50% 的网站外观/功能将被共享）。
我们正在努力做的是尽可能保持干净，以便多个团队轻松工作并易于维护。
我们已经考虑/正在尝试的一些事情： 发动机。让每个应用程序成为一个引擎。这将使我们能够在域上建立基础路由。它还允许我们提取特定应用程序的控制器、模型和视图。该解决方案似乎并不理想，因为我们不会很快重用这些应用程序。并且在路由中明确说明主机似乎并不正确。
换肤/主题。应用程序之间的身份验证逻辑会有所不同。每个用户模型都会有所不同。所以这不仅仅是一个皮肤问题。
在 app/view 中，为 sitea 视图添加文件夹 sitea，为 siteb 视图添加 siteb 文件夹，依此类推。对控制器和模型执行相同的操作。这仍然相当混乱，并且由于它不遵循命名约定，因此它不能很好地与 Rails 配合使用，并且使大部分代码变得更加混乱。
制作另一个 Rails 应用程序。我们只是不想在两个应用程序中维护相同的控制器或视图（如果它们相同）。
我们想要做的是让应用程序智能地使用基于主机的控制器。因此，每个应用程序都会有一个会话控制器，也许还有一些用于共享逻辑的父会话控制器（现在不需要）。在每个会话控制器中，它处理该特定应用程序的身份验证。因此，如果域是 a.mysite.com，它将使用应用程序 a 的会话控制器，并知道使用应用程序 a 的视图、模型、控制器。如果域是 b.mysite，它将使用 b 的会话控制器。并且将有a的用户模型和b的用户模型，这也将由领域确定。
有人对这种情况有什么建议或经验吗？理想情况下，使用 Rails 2.3.x 作为更新到 Rails 3 目前并不是一个选择。
Background:
We have app a, b, and plan to add more apps into this same application. The apps are similar enough they could share many views, assets, and actions. Currently a,b live in a single rails app(2.3.10). c will be similar enough that it could also be in this rails app.
The problem:
As we continue to add more apps to this one app, there's going to be too much case logic that the app will soon become a nightmare to maintain. There will also be potential namespace issues. However, the apps are very similar in function and layout, it also makes sense to keep them in one app so that it's one app to maintain(since roughly 50% of site look/functionality will be shared).
What we are trying to do is keep this as clean as possible so it's easy for multiple teams to work on and easy to maintain.
Some things we've thought about/are trying:
Engines. Make each app an engine. This would let us base routes on the domain. It also allows us to pull out controllers, models and views for the specific app. This solution does not seem ideal as we won't be reusing the apps any time soon. And explicitly stating the host in the routes doesn't seem right.
Skinning/themes. The auth logic would be different between the apps. Each user model would be different. So it's not just a skinning problem.
In app/view add folder sitea for sitea views, siteb for siteb views and so on. Do the same for controllers and models. This is still pretty messy and since it didn't follow naming conventions, it did not work with rails so nicely and made much of the code messier.
Making another rails app. We just didn't want to maintain the same controller or view in 2 apps if they are identical.
What we want to do is make the app intelligently use a controller based on the host. So there would be a sessions controller for each app, and perhaps some parent session controller for shared logic(not needed now). In each of these session controllers, it handles authentication for that specific app. So if the domain is a.mysite.com, it would use session controller for app a and know to use app a's views,models,controllers. And if the domain is b.mysite, it would use the session controller for b. And there would be a user model for a and user model for b, which also would be determined by the domain.
Does anyone have any suggestions or experience with this situation? And ideally using rails 2.3.x as updating to rails 3 isn't an option right now.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Devise 正是这样做的。您最好检查一下它的架构并将该架构应用到您自己的案例中。
您将拥有多个独立的 Rails 应用程序。共享代码将是一个单独的项目，可能作为 gem 分发，或者至少是一个单独的 Git 存储库。共享代码将包括许多控制器操作和许多视图模板，这些模板是合理的默认值，并且在某些应用程序中将被覆盖，但在其他应用程序中不会被覆盖。
应用程序 A 的所有自定义代码都将属于一个专门用于包含应用程序 A 的自定义代码的项目。它将是其自己的功能齐全的 Rails 应用程序，并将在很大程度上依赖于共享代码提供的大部分合理默认值。共享代码项目。
Devise does exactly this. You would do well to check out its architecture and apply that architecture to your own case.
You will have multiple separate Rails applications. The shared code will be a separate project, perhaps distributed as a gem or at least a separate Git repository. The shared code will include many controller actions and many view templates that are there to be sensible defaults, and which will be overridden in some apps but not in others.
All the custom code for application A will belong in a project solely devoted to containing the custom code for application A. It will be its own fully-functioning Rails application and will depend heavily on the majority of the sensible defaults provided by the shared code in the shared-code project.
我之前使用过主题支持插件，并根据请求 uri 动态设置主题：
http:// /mattmccray.com/svn/rails/plugins/theme_support
它可能需要一些工作来支持 Rails 2.3。
更新：看起来有重写：https://github.com/dasil003/ Rails-多站点
I've used the theme support plugin before and dynamically set the theme based on the request uri:
http://mattmccray.com/svn/rails/plugins/theme_support
It will probably need some work to support Rails 2.3.
Update: Looks like there's a rewrite: https://github.com/dasil003/rails-multisite
听起来您想让“基本”应用程序成为一个插件，并在每个网站应用程序中使用它。您可以使用 svn-extern 之类的东西，这样每当有变化时它就会自动更新。
Sounds like you want to make the 'base' app a plugin and use that in each of your site apps. You can use something like svn-extern so it's automatically updated whenever something changes.