Service Objects vs Service Mixins about overholt HOT 4 CLOSED

You are right. I use a similar pattern in my code except I only have get, save, and delete operations.

from overholt.

It's a matter of design, which we can argue all day if you want 😏, and thats because design is a matter of opinion. If that works for you, thats fine. I, however, don't like to mix responsibilities in my objects. For example, I don't believe this mixin approach is appropriate when you begin to have more complicated business logic when instances of your models are created, updated, or deleted. A hypothetical scenario might be that, when you create a Product record you must also publish a message to a message queue. In my opinion, it would be inappropriate to encapsulate that logic in a class method on the Product model class. More appropriate would be an object that brings together separate functions that deal with both operations, making the logic easier to test.

from overholt.

Come to think of it, I agree with you on that part. Using service models let's you draw the line between disparate systems.

So just one final question, why not make the methods in the service object static?

EDIT: I initially opened this topic to obtain clarification on why certain design decisions were made in the project template. After given that example, I got a better understanding why it was designed the way it was.

Anyway, I was trying to get away from instantiating the service (especially since I didn't need multiple service objects with different configurations). The service object will definitely need to be instantiated if you want to create differently configured services, and that's why this exercise is pretty much a futile one.

Anyway, thanks a bunch! I had a small epiphany moment when thinking about this.

from overholt.

Awesome! Good luck in your work.

from overholt.