gaming_mouse,

I think you're confusing the theoretical benefits of a world in which we have fully-fleshed out DCI architecture and a useful framework that reinforces the design and developers who understand the concepts well with this:

https://github.com/collectiveidea/in...ree/master/lib

And the guy who wrote the blog article who seems to think the only alternative to interactors is having fat controllers/models and keeps talking about the benefits of POROs as though it's a counterpoint when DHH is arguing for POROs and he's arguing for interactor-based non-plain objects.

yes


no.

in this particular case, it probably doesn't matter much. how "ok" it is depends on the likelihood of this code being changed and more similar features being added. but there is also the fact of getting into good design habits when those habits actually cost you nothing.

gem? no, just a module.

no, you didn't gain complexity. you actually made things simpler and more testable. all you have to do is:

@article.extend(MyAwesomeReadingTimeEstimatesAndSh *t)

and now you can use it just like before. And now you haven't brought your super specific reading time estimate code and tacked it onto the article itself where it gets dragged along into every single other use case of an article that has nothing to do with estimating reading times.

DHH is not arguing for POROs, at least not in the posts that I read. He's arguing for putting that logic into AR models and essentially saying, hey, do things the kind of crappy way until you have a reason not to, because it's simpler and yagni.

This is a really common abuse of the ideas of simplicity and yagni imo, not just by DHH -- I see it a lot. Basically, yagni as an excuse to not have to design things well, and then when you run into people who actually care about design and do design things well you dismiss them by claiming over-engineering.

In this case, he's saying put the logic in the controller until it needs to be factored out. And he gave a PORO version:

https://gist.github.com/dhh/9333991

I think he's absolutely correct.

candybar,

i found the post you must have been thinking of:

https://gist.github.com/dhh/9333991

i do like that better, but the point it's still missing is that you have to test that business logic that's still in the controller by writing controller tests, which sucks. ideally, your controller should be so simple (just pure delegation) that you don't you even have to test it (you'd just be testing the framework at that point).

EDIT: looks like our posts crossed. and i still think he's wrong, although in that last example the amount of wrong is smaller.

Bought a rubymotion license. Seems very slick so far.

will be curious to hear your thoughts. have you done ios dev with obj-c before or is this your first foray?

Every software architecture is wrong in the long run. There's nothing necessarily wrong with fat controllers or fat models or whatever - just do what makes sense for your application and your (and your colleagues') level of expertise. "Business logic" is also not a well-defined phrase.

Anyway, I mostly wanted to highlight what doesn't constitute as learning and becoming a better programmer. If you want to become a better programmer, you have to get better at understanding and more importantly, utilizing at a high level, fundamental computational concepts, like functions, closures, promises/futures, actors, monads, type classes, semaphores, trees, graphs, parsers, compilers, unification, public-key cryptography, paging, garbage collection, heap allocation, memory hierarchy, etc. Learning new things helps, getting better what you already know is even better.

Learning frameworks and architectural fads, or in some cases, just learning how to structure boilerplate code that does nothing, may situationally make you more productive - and maybe that's all you care about - but won't have an impact 5-10 years down the road. In most cases, after enough time, you will be harder to work with and less desirable as a new hire you've accumulated more opinions than knowledge, many of which will be unpopular in the future.

i don't know if that blog post author understands this or not, but there are much deeper principles behind what he's doing than architectural fads or boilerplate, things which are applicable anywhere and not just in rails or web frameworks.

i actually think the general point you were making is a good one, and even your example is good, but it's DHH who is the illustration of the principle, not the blog post author :P

I think you're talking about something completely different. If controllers are going to be purely delegative, why have controllers at all? If you need to be able to test some logic separately, why not use a mixin instead? For instance, in Spray (in Scala, but same should work in Ruby), this is a common pattern:

https://github.com/spray/spray-templ...yService.scala

now we're speaking the same language!!

DHH is one of the very few people in this world who may be uniquely qualified about to talk about stock architectures and what belongs there and what doesn't. No one can possibly know what "architecture" will actually work best across the universe of applications and software development teams, but he's created an extremely popular framework whose architectural pattern was widely copied and became more or less universal among web frameworks. I mean I think I get your point about DHH being the kind of self-important person who is obsessed about the wrong things, but at least he's made a career out of it and is a very good programmer otherwise. Don't forget that pre-Rails frameworks tended to be full of random, complex, made-up concepts like what DHH is perceiving this as.

It's possible you or the blog guy is right and DHH is wrong but like DHH said, the proof is in the pudding. Would MVCDCI Rails be even more widely adopted and even more useful? It's possible, but I find most of the arguments unconvincing. It's not enough to show that concept X is useful in some situations and models something real - AbstractFactoryFactory passes that test. You have show that the benefit outweighs the cost.

Not sure what you'r getting at - it doesn't really matter what you call a controller. If you delegate everything, that other thing is essentially a controller. Maybe you have a problem with how routing work in Rails?

no, i want rails to handle web framework tasks: routing and http stuff. putting form variables into convenient hashes, etc. all the stuff that it's good for. if that's the work of a "controller," that's great. but it's a terrible, now entrenched and accepted practice to mix that stuff up with you business logic. you said before it wasn't a well defined term, so i'll clarify. sending emails in response to some action based on some rules, that's business logic. that's specific to your business. and if i want to test that, i sure as hell shouldn't have to be worrying about a rails base "controller" class, or about somehow mocking web requests just to setup my test. that stuff has nothing to do with the web, even. it's that mixing of concerns that i'm railing ( ) against.

for the record i'm bashing something very specific about him. i think he's a good speaker and i agree with a lot of his attitudes about programming. i just think he has a blind spot about legit criticism of rails.

oh i doubt it, but i don't consider that a counterargument. if popular and widely adopted are our benchmarks of good architecture, then spaghetti php code wins.

it's hard to design things well. most people can't do it. the standard rails way is much easier to understand than most better alternatives. it's sort of a chicken and egg problem, in that if better, alternative architectures had taken hold and become popular, they might be easier to learn now. so i'm not sure if they are fundamentally more difficult, or just more difficult within the framework of how most people currently think about things. but in either case, i agree: i don't see that shift happening anytime soon.

In that email situation, I'm not sure if the testing benefits are worth it as the only reason for separating it into the "modified" PORO version. When would you ever want to write an isolated test for the email part only?

Wouldn't you just do a controller test at most and test that it works as intended as a whole. That's certainly what I would do given the info we have atm.

I get what you're saying but why do you need anything beyond plain Rails and plain Ruby to solve this? You can use some combination of mixins and explicit delegation to POROs, depending on the situation.

DCI, or what blog post guy is doing, or service objects, or any of the variations whatever you want to call them aren't, in the end, anything more than what you suggest. but if you're using that pattern a lot, it makes sense to have some supporting code to avoid repetition. you certainly don't have to, though. i don't care for the name "Interactor" at all, maybe that's what you're responding to? i've noticed in general a lot of fundamentally good architecture is spoiled by complicated, impressive-sounding nomenclature. but it's worth looking past that to the underlying ideas.

if the controller is pure delegation, there's nothing to test there. whatever you would be testing in a controller test, you put those tests against what is now a PORO, and trust that the rails framework works, so you don't even have to write a controller test. the point is testing controllers is awkward and weird and you have to mock the whole context of a web request, all that stuff has nothing to do with the logic you are testing.

In the email situation I'm talking about the methods moved from being a private method on the controller to a PORO that does nothing but call 3 rails mailers.

You're now testing that you have a class capable of calling 3 rails mailers which seems like the exact thing you think is useless to test (which I agree with btw).

I'm for only testing enough just to make sure things work while trying my best to avoid double testing the same code path or things that are already well tested.

If I wanted to test those mailers on their own I can do that because rails makes it simple to test them without a controller. As stated earlier I like DHH's approach of putting them as priv methods on the controller and only making it a PORO when you have a need to use that group of functionality in another area of your code base.

I think the point is that factoring out common code in another method or even another class isn't some kind of advanced architectural pattern - it's one of the very first things you learn when you learn to program and a pattern that's part of virtually every single application architecture in objected oriented languages. Calling them "the missing parts" in Rails is dishonest and self-aggrandizing.

And the interactor implementation (https://github.com/collectiveidea/interactor) is obfuscatory - As far as I can tell it does nothing useful beyond obfuscating the control flow so that it's not clear what's going on. Correct me if I'm wrong but it doesn't seem to handle async at all? What does it add over a function that simply returns some kind of error code?

@Shoe,

you're testing the entire logic that's in the controller.
the if successful save, then send emails, otherwise return false.
the only part that would left for the controller is mapping that false to a redirect or whatever. look at the interactor example from the blog post: http://eng.joingrouper.com/blog/2014...ts-interactors

the refactoring DHH did to move just the emails part into its own object is not enough to achieve the testing benefit you want. so you are right, just doing what he did doesn't make much sense. you should go all the way or not at all.

This is going to be tough because almost every major stakeholder, including developers, is worse off in the short run and the only people who can plan for the long run are probably not technical enough to understand the vision. I spent a fair amount of political capital and a huge amount of time at my much smaller company over the past year and half trying to get people to buy into automated testing (along with other cultural/procedural changes) and had very limited success.

The other problem is that from a purely technical standpoint, user interface with lots of specific presentation elements, where requirements are precise, arbitrary and volatile, don't make good subjects for automated testing. Best tests are written at the level of unit of functionality, but in a lot of complex web sites that aren't quite applications with complex but systematic logic, there just isn't that much that can be tested at the level of a unit. Integration/E2E tests are nice, but they are much more brittle, much harder to write and maintain and far difficult to get to decent coverage.

First foray. I want to be able to build apps, but don't want to bother learning objective-c at this point. Will let you know how it goes.

sort of, but if it's so simple and obvious why does rails get it so wrong? it's not just factoring out common code -- you should be doing it even if you know you'll never reuse the code just for testability. the point is to decouple your framework from your business logic. rails architecture and culture explicitly encourages this coupling.

what is obfuscated? it makes a call to his interactor, which returns success or not, along with a message. the controller redirects or displays a message accordingly. you should be looking at the way interactor is used in the blog example, not at the source code. as a client you'd never be looking at that. i don't follow your point about async.