3 ms·
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 t
by 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 agoI 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 agoapp/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.