4 ms·

One of the things I've struggled with on large Rails projects is helping developers understand that they can and should write code is neither model, view, contr

One of the things I've struggled with on large Rails projects is helping developers understand that they can and should write code is neither model, view, controller, helper or lib. Instead a model ends up with a ton of class methods that are only somewhat related to fetching and storing records. A controller ends up with some crazy query that joins three tables and generates statistics. I would like to see some guidance from Rails on how and where to put these types of things. When I advocate for a service object, I get asked what the parent class would be and where the code would live. Saying no parent class and app/service_objects gets me some questionable looks like I'm not doing it right. Opinionated frameworks are great but I feel like people assume a lack of opinion to mean don't do it. I'm not sure what concrete steps rails can take, but maybe app/lib for application specific code and lib/ for more generic libraries. Or maybe something less confusing.

steveklabnik 13y ago
With 4.0 we included app/concerns, so that should help open up your conversations a bit.
- karmajunkie 13y ago
  Concerns are just geography, they do nothing to encourage single responsibility or domain design. [edit: rereading the parent, your reply was to where to put the code, and app/concerns is as good a place as any I guess, but I stand by the idea that concerns themselves are a bad idea.]
  - steveklabnik 13y ago
    I have publicly blogged about my dislike of them as well. But they do at least demonstrate there's more to an app than MVC, and that those directories go in app.
  - phamilton 13y ago
    app/concerns is a perfect example of the problem I'm trying to communicate. If I want to extract code out into a concern, everyone is perfectly ok with it because Rails has "blessed" the concern pattern by providing a parent object to inherit from and a directory where concerns should be placed. As soon as Rails weighs in with an opinion, everyone is onboard. I think the message I would like to see communicated is that we as developers are free to create app/foo if we feel like foo is a good idea. Technically there's nothing stopping it. Culturally, it's almost unheard of. I brought up lib/ because structurally it is a free for all. Nobody looks twice if I create lib/foo and add some code there. The problem is that I don't want to put app specific code into lib. I'm not sure if app/lib is a good idea, but I feel like it would communicate the idea that it is OK to write app specific code that doesn't fit into anything Rails has approved. Anyway, I realize my concern is very much a culture issue. That culture has its pros and cons, and if we didn't have the strong opinion to stick to MVC, we would probably end up with a ton of spaghetti code in app/lib. I just wish we could strike the right balance.

steveklabnik 13y ago

With 4.0 we included app/concerns, so that should help open up your conversations a bit.

karmajunkie 13y ago
Concerns are just geography, they do nothing to encourage single responsibility or domain design. [edit: rereading the parent, your reply was to where to put the code, and app/concerns is as good a place as any I guess, but I stand by the idea that concerns themselves are a bad idea.]
- steveklabnik 13y ago
  I have publicly blogged about my dislike of them as well. But they do at least demonstrate there's more to an app than MVC, and that those directories go in app.
- phamilton 13y ago
  app/concerns is a perfect example of the problem I'm trying to communicate. If I want to extract code out into a concern, everyone is perfectly ok with it because Rails has "blessed" the concern pattern by providing a parent object to inherit from and a directory where concerns should be placed. As soon as Rails weighs in with an opinion, everyone is onboard. I think the message I would like to see communicated is that we as developers are free to create app/foo if we feel like foo is a good idea. Technically there's nothing stopping it. Culturally, it's almost unheard of. I brought up lib/ because structurally it is a free for all. Nobody looks twice if I create lib/foo and add some code there. The problem is that I don't want to put app specific code into lib. I'm not sure if app/lib is a good idea, but I feel like it would communicate the idea that it is OK to write app specific code that doesn't fit into anything Rails has approved. Anyway, I realize my concern is very much a culture issue. That culture has its pros and cons, and if we didn't have the strong opinion to stick to MVC, we would probably end up with a ton of spaghetti code in app/lib. I just wish we could strike the right balance.