如何重构包含大量后端代码的 Rails 模型?

发布于 2024-11-06 02:31:46 字数 429 浏览 0 评论 0原文

我有一个包含 421 行代码/注释的 Rails 2.X 模型,它在后端执行大量工作(打开 HTTP Get 请求、解析 RSS、解析 HTML 等)。同时,我正在转向 Resque,以便更快地完成此后端代码。我想知道重构这个的最佳方法是什么。我应该将此后端代码移至模型中包含的库吗?一个模块?宝石?

非常感谢您的想法。

我基本上为我正在处理的每个数据项都有一个单独的核心任务。即解析 RSS 提要、解析 HTTP URL、在该 html 主体上运行正则表达式,以及一些其他任务,现在我在模型中有 500 行代码;尽管模型所做的大部分工作都是通过 cron 运行的后端脚本调用的,

因此使其更加实用并更容易迁移到 resque;我正在考虑为每个 resque 队列创建单独的类,并在那里使用静态方法

然后,如果您愿意,我可以通过后端“控制器”脚本要求这些类...这种方法有意义吗?

I have a Rails 2.X model with 421 lines of code/comments that does a significant amount of work on the backend (opening HTTP Get requests, parsing RSS, parsing HTML, etc.). At the same time, I'm moving to Resque in order to more quickly get through this backend code. I'm wondering what the best way to refactor this would be. Should I move this back-end code to a library that I include in the model? A module? A gem?

Your thoughts would be much appreciated.

I basically have a separate core tasks for each data item i'm processing. i.e. parsing an RSS feed, parsing a HTTP URL, running regex on that html body, as well as a few other tasks and right now i have 500 or lines of code within the model; even though most of the stuff the model does is called through a back-end script run by cron

So to make it more wieldy and to make it easier to move to resque; i was thinking of doing separate classes for each resque queue, and using static methods there

Then I can require those classes by the back-end 'controller' script if you will... Does this approach make sense?

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

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

发布评论

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

评论(3

白云悠悠 2024-11-13 02:31:46

从可测试性和思维过程的角度来看,您最好的选择可能是将这些不同的问题分解为它们自己的(非 ARec)模型。根据您的第一段,您可能有 RssParser、HtmlParser、ServiceRequest 等。

根据这些东西的使用位置(多个项目?),制作自己的 gem 并对其进行版本控制可能是有意义的。

我以前写过大大小小的resque 类,如果你让resque 类尽可能精简,你会省去很多痛苦。

Your best bet from a testability and thought process standpoint is probably to break out those various concerns into their own (non-ARec) models. You might have RssParser, HtmlParser, ServiceRequest, etc., based on your first paragraph.

Depending on where this stuff is used (multiple projects?), it might make sense to make your own gem and version it.

I have written big and small resque classes before, and you'll save yourself a lot of pain if you make the resque classes as thin as possible.

客…行舟 2024-11-13 02:31:46

所讨论的模型正在做很多事情。

在结构良好的应用程序中,每个类都做一件事并且做得很好。结构良好的应用程序的这一特性是其高度可测试性的一部分。

您应该将一个模型所做的许多事情分解为多个独立的类,使它们之间的依赖关系保持最小。然后,您将能够轻松测试每个新类,并且您将有许多新的存根点来测试整个模型。

The model in question is doing many things.

In a well-structured application, every class does one thing and does it well. This feature of a well-structured application is part of what makes it highly testable.

You should break apart the many things that the one model does into multiple self-contained classes, keeping the dependencies between them minimal. Then you will be able to test each of those new classes easily, and you will have a number of new stub points to test the overall model.

昔日梦未散 2024-11-13 02:31:46

根据我的经验,如果这段代码要在多个应用程序中使用,也许 gem 值得考虑。否则,通过将代码移动到 gem 来添加间接层似乎不会产生太多好处。事实上,根据您的部署情况,它可能会减慢开发速度。

至于如何重构模型,请查看所有模型的代码,并像你自己一样问“这个模型在做什么?”。如果最终有很多“and”或“or”,那么您可能应该努力使每个项目由“and”或“or”分隔为自己的类(请参阅http://en.wikipedia.org/wiki/Single_responsibility_principle)。以这种方式分解职责使得单独的关注点更容易编写测试。特别是在进行外部 HTTP api 调用等时。

In my experience, if this code is going to be used in more than one application, maybe a gem is worth considering. Otherwise, adding the layer of indirection by moving the code to a gem doesn't seem to yield much benefit. In fact it can potentially slow down development depending on your deploy situation.

As for how to re-factor the model, look through all the model's code and as yourself the question "What is this model doing?". If you end up with lots of 'and's or 'or's, then you should probably strive to make each item delimited by 'and' or 'or' its own class (see http://en.wikipedia.org/wiki/Single_responsibility_principle). Breaking out the responsibilities in this manner makes the individual concerns much easier to write tests against. Especially when making external HTTP api calls, etc.

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