Rails 模型有多复杂?示例项目?

发布于 2024-09-12 01:06:02 字数 311 浏览 3 评论 0原文

我正在尝试超越 Rails 的初级阶段并进入中级,但我发现很难找到更高级的示例来学习。

例如,我读到您需要小心“嵌套路由”并且深度不应超过 2。在这种情况下会发生什么?

  • 客户可以下很多订单
  • 订单可以有很多商品
  • 商品可以有多种类型的选项
  • 每种类型的选项都可以有限制:在某些日期可用,或需要选择,或影响总价等。

这是一个傻瓜差事还是简单的东西对于轨道。我假设是后者,但找不到任何有趣的示例项目(源)可供学习?书籍似乎停留在基础知识......想法?

I'm trying to move past the beginner stage of Rails and into the intermediate but I'm finding it hard to find more advanced examples to learn from.

For example, I've read that you need to be careful about "Nested Routes" and shouldn't go more than 2 deep. What happens in a situation like this?

  • Customer can place many Orders
  • Orders can have many Items
  • Items can have many types of Options
  • Each type of Option can have restrictions: available on certain days, or requires a selection, or affects total price, etc.

Is this a fools errand or simple stuff for Rails. I'm assuming the latter but can't find any interesting example projects (source) out there to learn from? Books seem to stop at the basics... ideas?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

小瓶盖 2024-09-19 01:06:02

您可以根据需要深入嵌套路由,但请记住,您可以并不意味着您应该这样做。你挖掘得越深,你为自己创造的工作就越多。

我看到的模式是,对于每个深度级别,您需要创建一个处理父参数的基本控制器和一个处理细节的子类。这往往是这样的:

Customer::BaseController < ApplicationController
CustomerController < CustomerController:: BaseController

Customer::Orders::BaseController < Customer::BaseController
Customer::OrdersController < Customer::Orders::BaseController

Customer::Orders::Items::BaseController < Customer::Orders::BaseController
Customer::Orders::ItemsController < Customer::Orders::Items::BaseController

在每种情况下,BaseController 都会以通用方式处理参数的加载和解释,例如:

class Customer::BaseController < ApplicationController
  before_filter :load_customer

protected
  def load_customer
    @customer = Customer.find(params[:customer_id] || params[:id])
  rescue ActiveRecord::RecordNotFound
    render(:partial => 'customer_not_found', :layout => 'application', :status => :not_found)
  end
end

正如您所看到的,如果您以这种方式规划应用程序,它可能会变得有点复杂。你最终也会有很长的路线。

如果您的数据库设计为使记录相当自治,并且可以从中推断出许多关系信息,那么您不一定需要遇到所有这些麻烦。订单页面可以提供到 @order.customer 的链接,而无需在路径中包含 customer_id。

You can go as deep with nested routes as you want, but keep in mind that just because you can doesn't mean you should. The deeper you dig, the more work you're creating for yourself.

The pattern I've seen is that for each level of depth, you need to create a base controller which handles the parent parameters, and a subclass which handles the specifics. This tends to play out along the lines of:

Customer::BaseController < ApplicationController
CustomerController < CustomerController:: BaseController

Customer::Orders::BaseController < Customer::BaseController
Customer::OrdersController < Customer::Orders::BaseController

Customer::Orders::Items::BaseController < Customer::Orders::BaseController
Customer::Orders::ItemsController < Customer::Orders::Items::BaseController

The BaseController in each case handles the loading and interpreting of parameters in a generic manner, such as:

class Customer::BaseController < ApplicationController
  before_filter :load_customer

protected
  def load_customer
    @customer = Customer.find(params[:customer_id] || params[:id])
  rescue ActiveRecord::RecordNotFound
    render(:partial => 'customer_not_found', :layout => 'application', :status => :not_found)
  end
end

As you can see it can get a little convoluted if you map out your application in this manner. You end up with really long routes as well.

If your database is designed so that the records are fairly autonomous, and a lot of the relationship information can be divined from them, then you don't necessarily need to go to all this trouble. An order page can provide linkages to @order.customer without having to have customer_id in the path.

凉城已无爱 2024-09-19 01:06:02

嗯,我同意你的观点,很多书都是从基础知识开始和结束的。

但如果你感到无聊,你应该坐下来想出一个想法。如果你正在做一个真正的项目,这总是最有趣的。
从示例和不真实的场景中学习可能会在一段时间内有所帮助,但在某些时候是时候接受一些挑战了。

就我个人而言,在读完《Rails 敏捷 Web 开发》之后我就不再看书了。然后我开始尝试自己的失败并从中吸取教训。

从理论上讲,您可以尝试为可能遇到的每种“中级”或“高级”情况做好准备。

老实说,我所遇到的问题与书本上的任何理论场景都没有关系。我必须坐下来,跟踪问题,阅读回溯,思考它们,谷歌搜索类似的问题,编写测试......这才是真正帮助我获得经验的东西。

走出去寻找或发展一个想法。如果你有,请编写测试并尝试实现它。
这会给你带来动力,也许你正在寻找。

注意:http://github.com 是查找源代码并查看的好地方。学习借鉴。

Hm, I agree with you that many books start and stop at basics.

But if you're bored you should sit down and develop an idea. It is always the best fun if you're working on a real project.
Learning from examples and unreal scenarios may help for some time, but at some point it's time to get some challenge.

Personally speaking I stopped reading books after finishing "Agile Web Development with Rails". Then I started making my own failures and learned from them.

Theoretically speaking, you can try to prepare yourself for every 'intermediate' or 'advanced' situation you might get into.

Honestly speaking, the fights I've fought with problems in my way weren't related to any theoretical scenario found in books. I had to sit down, track the problem, read backtraces, think about them, google for similar problems, write tests... This is what really helped me gaining experience.

Go out there and find or develop an idea. If you got one, write tests and try implementing it.
This will give you the boost, you are maybe looking for.

Note: http://github.com is a great place to find source code to look at & learn from.

情徒 2024-09-19 01:06:02

看看 opensourcerails.com - 找到您感兴趣的应用程序,获取源代码并浏览它一块一块。在本地运行它,找到有趣的功能,然后进入代码看看它是如何完成的。

Have a look at opensourcerails.com - find an app that interests you, grab the source, and go through it piece by piece. Run it locally, find the interesting functionality, then get into the code to see how its done.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文