Crazy, Heretical, and Awesome: The Way I Write Rails Apps
jamesgolick.com
jamesgolick.com
So do I need service objects? Well, I don't know what the author of this fine post calls them, but I am using the Observers baked into Rails, a pattern that goes back to Smalltalk in the 1980s. I tell Rails that my NotificationObserver is observing my Game and Action models, and the concern of notification is separated from the concerns of playing games.
Is "Observer" the wrong word? Or worse, the wrong pattern?
In the case of logging, an observer may or may not be appropriate depending on the specifics of your application. In your Go app, it sounds like a NotificationObserver makes perfect sense.
The broader point that I was trying to make in the article was that coupling all of your business logic to your persistence objects is a bad idea. It couples all of the concerns together, and with larger codebases, makes for slow tests and code that's difficult to reason about and debug.
If your business logic lives outside of your persistence layer, service objects can be a great way to coordinate several objects necessary to complete some user action. Observers can work quite well too.
As long as business logic is decoupled from persistence, I think a big step has been made towards better code.
Rails 3 makes it easier to swap out controllers and routers. (It also loads everything under app/ by default, so you can name app/observers or app/services without having to add in extra load paths by hand). It should not be difficult to implement a parallel workflow engine, for example, that uses a shared persistence stack (models) yet manages data lifecycle, and respond to messages rather than stateless RESTful resource APIs.
Good thoughts, good article.
I'd be curious to hear your thoughts on that piece.
Still, at least doing the right thing is not only possible, but generally easy once you've broken your mind out of the prescriptions of the framework.