5 ms·
The thing is... in Rails app, the Controller is slowly becoming THE service layer. In the past literatures written mostly for enterprise projects, Service laye
by edwinnathaniel 13y ago
The thing is... in Rails app, the Controller is slowly becoming THE service layer.
In the past literatures written mostly for enterprise projects, Service layer (http://martinfowler.com/eaaCatalog/serviceLayer.html http://martinfowler.com/eaaCatalog/serviceLayer.html) answers to multiple interfaces.
Fast forward to today, Rails Controllers become the API which other interfaces can consume via JSON, XML, or even HTML or simply stream of texts if configured.
If you can dictates that "here's an endpoint that you can poke, I will not provide WS-*" (in other words: you can dictate the requirements), then there's no need for a service layer.
- mercurial 13y agoUh. In any complex application, you write services which are responsible for various business needs, and whose responsibilities only loosely overlap the way your webapp is accessed from the outside. You may even have services only used by other services. And obviously, stuffing your business logic along with your web glue (whatever concrete representation you're sending to the outside, you're still stuffing parameters in a template, essentially) still violates SRP. Not to mention that it makes it utterly impossible to reuse outside of your web application, something which is sometimes desirable.
- edwinnathaniel 13y agoI don't disagree with you. In fact, I am writing those services whether it is for the API component or in the web glue on projects I worked on. I'm just pointing out that there are a fraction of Rails crowd that don't think these services are needed is partly because of how things work in Rails.