About Injecting a service in model


Recently myself and a friend of mine had discussion about injecting a service inside a model. We knew that model are just used to represent and store data but my friend was just curious to know what’s wrong and downside of injecting a service inside a model. His argument is if service is injected to a model we can use that service to retrieve data?

Could some one please explain briefly is it a good practice to use a service in a model?


If team members are looking where the data is retrieved they would expect that on the route or adapter. So unless the app is maintained by one developer I would not think this is a good practice.

Proper way to define data that comes back as a query

Thanks for your reply. yes we are a big team so this would lead to confusion on the approach followed.


@indvinoth I’d also add that on a more conceptual level it’s breaking the separation of concerns and could cause problems down the road. Essentially it’s a bad design compromise. The model is just supposed to define how your data should be represented. So it’s “concern” is just saying "here is a collection of attributes and their types, and it is named ". You can have computed properties on a model which can transform the data a little bit or format it differently but in generally your model should just be a blueprint for some data. That means a model should never do data fetching or rendering or other things that are outside its limited realm of responsibility. A model should never be aware of the global application state, or really any state outside of itself, and a service usually represents some kind of global app state.

So you could argue that because you can do something, why not do it? Or perhaps that since everything is just a javascript object it’s not that weird. But I would say that the conceptual ideas like models, controllers, views, routes, etc. exist for a reason and that is to keep your code organized and well designed. Violating these design best practice can lead to some pretty bad problems later on. I’m not one to be too dogmatic about any one design pattern or way of doing things, but sticking to convention and best practice as much as possible can make your life a lot easier.


Unfortunately sometimes you have models that have computed properties and a common service is feature-flagging. Sometimes the properties that you compute on a model is based on what features you have enabled in the application.

To have to rip out computed-properties from a model simply because you now depend on feature-flag information seems quite silly.


The argument above is to not load data in models, not to not ever inject any service into models. The title “About injecting a service in model” is misleading but if you read it carefully.

I think your use case, injecting a feature flagging service into models, is a totally valid one.