Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails – The Missing Parts

eng.joingrouper.com

Post reply on HN
Print view View original

91–100 of 173 posts

Re: Rails – The Missing Parts

#91

Post by rubiquity »

dhh wrote: post #52
dhh wrote: post #47

Earlier quoted context omitted.

I rewrote the code in this example to use the "Beginner's Version" of Rails ( sigh ). You judge which you like better: https://gist.github.com/dhh/9333694

Here's another version that doesn't even use private methods in the controller and uses a PORO for the email grouping: https://gist.github.com/dhh/9333991

I think a lot of blog posts use trivial and contrived examples for the point of explaining the concept. There's not a lot of people out there that are good at explaining complicated refactorings. Katrina Owen comes to mind as one of the few that is good at explaining such refactorings.

Perhaps if someone made a post like this with starting code that was more complex it would be a better example, and also harder for you to counter it with a couple gists ;)

Re: Rails – The Missing Parts

#92

Post by rafekett »

dhh wrote: post #39

The proof is always in the pudding. While there are good and reasonable times to introduce "interactors", this particular example is poor. The tests presented are anemic, and the code is absolutely not any clearer by being extracted and wrapped. I would indeed have kept all this in the controller. The key point for an "interactor" extraction is imo when you have multiple models being created in symphony, like a Signu…

the example is poor, butI think you're missing the core point here -- slow tests. I don't think this really improves readability or organization much -- but my real world experience with a giant slow rails test suite gives me 100% confidence that patterns like this are the only way to not have a completely intractable giant test suite.

Re: Rails – The Missing Parts

#93

Post by AndyDavis3416 »

hkarthik wrote: post #85
AndyDavis3416 wrote: post #78

Earlier quoted context omitted.

Perhaps that's why the OP used a simple example. Complex examples are pretty hard to get your head around at first glance; even sane systems can be perceived as a 'hot mess' upon a quick read without any context. I disagree that re-assigning a case belongs in the case model. It is a complex interaction between several models. Extracting it to a command object allows all of the rules to be easily understood.

I feel like showing off some tests would help when the example is this complex. That would give a bit more context in terms of what you're trying to accomplish here.

True, the tests do demonstrate what can be accomplished, but that kind of gets back to my point: Any example complex enough to unambiguously warrant the use of a command pattern is going to involve non-trivial effort to learn the context. Asking that effort of someone reading a blog post is a bit much.

Unfortunately, it's easy to dismiss simple examples as not being worth the complexity and demand real examples which can be dismissed because they cannot be easily understood.

Re: Rails – The Missing Parts

#94

Post by akmiller »

gnaritas wrote: post #77
dhh wrote: post #71

Earlier quoted context omitted.

If reassigning a case is part of the domain, it belongs in the model. I don't know how to put this gently, but this concoction looks like a hot mess with no separation between modeling and controlling. These commands have a ton of domain logic all tangled up with activity reporting, formatting, and parameter parsing. It looks like a big ball of mud to me :(

> It looks like a big ball of mud to me :( That is of course the most popular of all architectural patterns. :)

Most popular by what metric?

Re: Rails – The Missing Parts

#96

Post by ollysb »

ollysb wrote: post #2

Perhaps because it's written with examples in java but I often feel like no one in the rails community has ever read Eric Evan's Domain Driven Design[1]. It's far and away the best material I've ever seen on how to organise large code bases. It covers pretty much every suggestion that I've seen from the rails community. Sometimes the rails community can feel like the fitness industry, everybody just rebranding things…

There's also a condensed version for free over at infoq[1](requires registration, but definitely worth it).

[1] http://www.infoq.com/minibooks/domain-driven-design-quickly

Re: Rails – The Missing Parts

#98

Post by grey-area »

tomblomfield wrote: post #6
ollysb wrote: post #2

Perhaps because it's written with examples in java but I often feel like no one in the rails community has ever read Eric Evan's Domain Driven Design[1]. It's far and away the best material I've ever seen on how to organise large code bases. It covers pretty much every suggestion that I've seen from the rails community. Sometimes the rails community can feel like the fitness industry, everybody just rebranding things…

Sure - I don't think anyone in the Rails world is claiming to have invented these principles. The problem is that Rails ships with a very limited set of core architectural concepts, and many inexperienced Rails developers feel like they've got to cram all of their code into a Model, View or Controller. Once your codebase reaches a certain complexity, principles from other programming paradigms are extremely useful.

To be fair, Rails does have concerns which let you easily compose your models out of modules, rather than having big god-object models, and it is easy to load other arbitrary collections of code too. So it is not really limited to MVC.

For beginners, I'm not sure it would be helpful to introduce a whole load of named patterns, as it just leads to cargo-culting and overuse of patterns without understanding whether they even apply.

It was interesting to read about a different approach though - thanks for the article.

Re: Rails – The Missing Parts

#100

Post by grey-area »

tomblomfield wrote: post #36
tzaman wrote: post #7

We tried using DHH's concerns in place for interactors, but ditched them for PORO/service objects because they can be tested outside Rails.

Yeah - I feel like concerns are a bit of an anti-pattern, especially as they're normally used in Rails. You've got a God class that exposes 500+ public methods, so you split it into concerns. But now you've still got a God class with 500 methods that's split across 10 files. Good luck understanding that. Concerns are useful when they're genuinely sharing functionality between classes - not just for splitting up "Big…

Concerns are useful when they're genuinely sharing functionality between classes

I've found them genuinely useful for that - there is a lot of code for things like urls, publish status, ratings, roles, permissions etc that can be shared between models if they have similar functionality.

They're just a recognition that composition via modules is often better than inheritance.

Post reply on HN