Comment by sodapopcan | Hacker News Reader

Comment by sodapopcan | Hacker News Reader

Parent Full thread

> * It's my view that MVC (and therefore Rails otb) is not ideal by itself to write a production-ready app, because of the missing service layer.

This is quite the claim. I despise service objects, personally. They end up scattering things around and hurt discoverability. There are other ways to do modelling that scale very well. There are a few blog posts on it, here's one from someone at Basecamp: https://dev.37signals.com/vanilla-rails-is-plenty/

This is of course very OO which I'm not a huge fan of. Elixir's Phoenix framework, for example, uses "contexts" which is meant to group all related functionality. In short they could be considered a "facade."

In any event, if you like services you like services, they can work, but saying MVC isn't enough for production-grade is a bit misguided.

I do agree that model callbacks for doing heavy lifting business processes is not great, though for little things like massaging data into the correct shape is pretty nice.

It would help a lot if you would clarify what you mean by “service object”. In my experience a single method on a service object would define a transaction. Is that what you mean by “service object”?

Along the lines of what OP is talking about, part of the problem is that Rails has no service objects, so I have seen a handful of different ideas of what they mean (probably no more than 10).

The one I've seen he most is stuff like `UserRegistrationService` or the like. These things can end up getting scattered and in general, I would rather just talk to the business object, ie, `User.register` which can delegate to a more complex private object handling it. It's basically "inverting" things. The win here is that things are more discoverable (You can look at the user object and see a list of everything it does) and more importantly draws better boundaries. This way the web layer only has to know about `User` instead of `RegisterUserService` and `DeleteUserService` etc.

Again, services can work and aren't inherently bad, but plain MVC can certainly also work.

I feel like the same people that like UserRegistrationService will argue that database table names should be plural because it reads better, which is wrong for similar reasons.

I don’t really follow. My focus wasn’t on the naming but the location of responsibilities.

I understood. Perhaps my mental connection was somewhat flimsy though. I was trying to make a tongue-in-cheek joke about how whenever I work on a database that has tables with overloaded responsibilities (poor normalization) instead of proper foreign keys they often also coincidentally have poor, plural names. Whenever I encounter such a thing, I think about the story of how it became that way. Usually part of the story includes a developer looking for a place to stick some logic and deciding an arbitrary place seems good enough because it’s a bit vague.

How are plural names linked to those things, though? I have a low-care level for naming conventions so long as there are conventions. Many successful frameworks use plural tables names. Though I agree singular probably makes a little more sense, especially since it eliminates the need for inflection code.

Your UserRegistrationService(s) is/are also prone to be overloaded. You don’t think of that as part of a naming convention? Would you argue that’s more about architecture? I was simultaneously agreeing with you and adding that this other minor organizational annoyance I have adds to the pile. Apologies if that seems low value.

I think service is an overloaded term. It's so generic that you can probably attach dozens of meanings to it, but here's two: One interpretation is a piece of code that doesn't neatly fit in one domain object (domain service). The other is a piece of code grabbing stuff from the db, orchestrating some domain methods, maybe wrapping it in a transaction, and exposing all that as an endpoint (application service). I think one of you has one in mind and the other the other.

At my last project, they did "service oriented development" and everything was either a service, a viewmodel or a test. For example aLogService, a ValidationService, or an AggregationService.

> I think one of you has one in mind and the other the other.

This is very possible.

Reply on news.ycombinator.com