递归 Rails 嵌套资源 [英] Recursive Rails Nested Resources

问题描述

我有一个用于项目管理的 Rails 应用程序，其中有项目和任务模型.一个项目可以有很多任务，但一个任务也可以有很多任务，无穷无尽.

I have a Rails application for project management where there are Project and Task models. A project can have many tasks, but a task can also have many tasks, ad infinitum.

使用嵌套资源，我们可以有/projects/1/tasks、/projects/1/tasks/new、/projects/1/tasks/3/edit 等

Using nested resources, we can have /projects/1/tasks, /projects/1/tasks/new, /projects/1/tasks/3/edit etc.

但是，您如何以 REST 方式表示任务的递归性质?我不想再深入一层，所以也许可以这样做:

However, how do you represent the recursive nature of tasks RESTfully? I don't want go another level deep, so perhaps the following would do:

map.resources :tasks do |t|
    t.resources :tasks
end

那会给我以下网址:

/tasks/3/tasks/new   
/tasks/3/tasks/45/edit

或者当涉及到单个任务时，我可以使用/tasks/45/edit

Or perhaps when it comes to an individual task I can just use /tasks/45/edit

这是一个合理的设计吗?

Is this a reasonable design?

相机

推荐答案

在单个嵌套路由之外的任何地方通常被认为是一个坏主意.

Going anywhere beyond a single nested route is generally considered a bad idea.

来自Rails 之路的第 108 页:

From page 108 of The Rails Way:

"Jamis Busk 是 Rails 社区中非常有影响力的人物，几乎和 David 本人一样.2007 年 2 月，在他的博客中，他基本上告诉我们深嵌套是一件_坏事，并提出了以下经验法则:资源不应嵌套多于一层很深."

现在有些人会对此提出异议(在第 109 页讨论过)，但是当您谈论将任务与任务嵌套时，它似乎没有多大意义.

Now some would argue with this (which is discussed on page 109) but when you're talking about nesting tasks with tasks it just doesn't seem to make much sense.

我会以不同的方式处理您的解决方案，就像上面提到的那样，一个项目应该有很多任务，但是对于一个有很多任务的任务来说似乎不正确，也许这些应该重新命名为子任务或类似的东西.

I would approach your solution a different way and like it was mentioned above, a project should have many tasks but for a task to have many tasks doesn't seem correct and maybe those should be re-named as sub-tasks or something along those lines.

这篇关于递归 Rails 嵌套资源的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！