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

11–20 of 173 posts

Re: Rails – The Missing Parts

#11

Post by pothibo »

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.

Problem with your assumptions is that inexperienced developers do not understand architectural concepts.

So you could cram every design pattern known to man and they would still cram everything in their controller.

API's are hard to discover and it takes time through trial and errors or being teached the way things are.

Re: Rails – The Missing Parts

#12

Post by edwinvlieg »

We've also come across the limitations of Rails as a one-size-fits-all solution for larger codebases. I don't think this is a fault of Rails, but more of the developers using the framework. Software engineering in general has more focus on a wide variety of design patterns and doesn't limit itself to one framework. In my opinion, Rails is the best framework to create wonderful web applications. Modeling business logic requires different kind of architectures than the simple MVC-ish structure Rails provides.

At MoneyBird we are using the Mutations gem to represent something like the interactors mentioned in this article. One major advantages of Mutations, is that is also does input filtering.

https://github.com/cypriss/mutations

Re: Rails – The Missing Parts

#13

Post by wdewind »

This is great, and does not only apply to Rails. In many other frameworks it's common to lump business logic in controllers instead of models. Either way you end up with the same thing: eventually you'll need to add a 4th (at least) type on to MVC.

> Here at Grouper, we’re long-time users of Ruby on Rails – along with other New York startups like RapGenius, Etsy and Kickstarter.

Etsy doesn't use Rails though, it uses PHP.

Re: Rails – The Missing Parts

#14

Post by troels »

One thing I can't figure out is whether to place my service objects under `/app/models` or under `/lib`. There doesn't seem to be a clear consensus on this? I tend more towards the former, because autoload works better during development. Also, I consider them part of my domain model. What do you do?

Re: Rails – The Missing Parts

#15

Post by rubiquity »

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.

I don't like Concerns because usually they are just hiding behaviors in another file (I do like routing concerns though!). You can test Concerns outside of Rails though, all you need is ActiveSupport which actually loads quite fast.

require 'active_support/concern'

require 'my_cool_concern'

class DummyClass

  include MyCoolConcern
end

Re: Rails – The Missing Parts

#16

Post by lengarvey »

troels wrote: post #14

One thing I can't figure out is whether to place my service objects under `/app/models` or under `/lib`. There doesn't seem to be a clear consensus on this? I tend more towards the former, because autoload works better during development. Also, I consider them part of my domain model. What do you do?

There's nothing stopping you from creating extra folders under /app to contain various types of service objects. Personally I have:

  /app/factories - for classes which create active record objects
  /app/services - for classes which do something I generally don't care about the return value of. Often perfect for background jobs.
  /app/decorators - most of these are Draper classes
  /app/forms - form objects
and a few others from various other gems.

Re: Rails – The Missing Parts

#17

Post by bphogan »

troels wrote: post #14

One thing I can't figure out is whether to place my service objects under `/app/models` or under `/lib`. There doesn't seem to be a clear consensus on this? I tend more towards the former, because autoload works better during development. Also, I consider them part of my domain model. What do you do?

I have app/services and just add that in application.rb to the load path.

Re: Rails – The Missing Parts

#18

Post by philwelch »

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.

Interactors, domain objects, service objects, etc. are still models; people just don't generally believe that their models are allowed to inherit from things other than ActiveRecord::Base.

Re: Rails – The Missing Parts

#19

Post by rubiquity »

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.

> "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."

The problem is that people think Rails is an architecture to begin with. Rails is just a framework that uses the MVC pattern (mangled slightly to fit the realm of HTTP). In the end, MVC is nothing but a directory structure for our files. What you put in those files and directories is up to you. Uncle Bob gave a great keynote on this called Architecture: The Lost Years. Here's a link: http://www.confreaks.com/videos/759-rubymidwest2011-keynote-...

Post reply on HN