Comments on: Grails Philosophy http://www.zorched.net/2008/05/01/grails-philosophy/ Musings of a software developer in Milwaukee, WI. Tue, 06 Jan 2009 10:30:20 +0000 http://wordpress.org/?v=2.7 hourly 1 By: blaxter http://www.zorched.net/2008/05/01/grails-philosophy/comment-page-1/#comment-14318 blaxter Fri, 28 Nov 2008 11:17:06 +0000 http://www.zorched.net/?p=103#comment-14318 services, adding a layer that does nothing, just expose funcionality already implemented. I'm with Geoff, logic to the model. Do you wanna foo service? Use the controller for making simple calls to the model layer, the same model could be use for rendering anything. (I guess Marc cames from java world, and he hasn't try frameworks like grails or similar stuff that makes things so much easier). services, adding a layer that does nothing, just expose funcionality already implemented. I’m with Geoff, logic to the model. Do you wanna foo service? Use the controller for making simple calls to the model layer, the same model could be use for rendering anything.

(I guess Marc cames from java world, and he hasn’t try frameworks like grails or similar stuff that makes things so much easier).

]]> By: Geoff Lane http://www.zorched.net/2008/05/01/grails-philosophy/comment-page-1/#comment-11231 Geoff Lane Sat, 03 May 2008 18:31:21 +0000 http://www.zorched.net/?p=103#comment-11231 Marc, Thanks for the comment. I don't mean to disparage using Services at all. It is of course a great way to share functionality. But whether logic is implemented in a Domain class or a Service, it can still be shared and exposed through multiple means.A Controller will most likely be used to expose those Services. Rendering an HTML page, XML for a REST service or other content is a content negotiation issue best managed by Controllers. That controller can interact with Domain objects or Services, whichever makes the most sense. I'm fighting the idea that everything needs to be encapsulated in a Service. In this mindset, Services often become simple pass-through objects that just add extra layers and more work without adding much value. Use Services when they make sense, but have a reason. Either way, thanks for the different perspective. Marc,
Thanks for the comment. I don’t mean to disparage using Services at all. It is of course a great way to share functionality. But whether logic is implemented in a Domain class or a Service, it can still be shared and exposed through multiple means.A Controller will most likely be used to expose those Services. Rendering an HTML page, XML for a REST service or other content is a content negotiation issue best managed by Controllers. That controller can interact with Domain objects or Services, whichever makes the most sense.

I’m fighting the idea that everything needs to be encapsulated in a Service. In this mindset, Services often become simple pass-through objects that just add extra layers and more work without adding much value. Use Services when they make sense, but have a reason.

Either way, thanks for the different perspective.

]]> By: Marc Palmer http://www.zorched.net/2008/05/01/grails-philosophy/comment-page-1/#comment-11230 Marc Palmer Sat, 03 May 2008 17:43:13 +0000 http://www.zorched.net/?p=103#comment-11230 Hiya... I disagree with your views on services. Services are great for all non-view preparation functionality. You should make controllers very thin like you say, but pushing too much functionality into domain classes is bad news, because even with logic related to a single domain class you may need to expose this functionality later as a SOAP, REST, XMLRPC or other service technology. Our domain classes are not anaemic - we put functionality related to the class in there in our apps, but typically this is very minimal on the basis that anything that is not just for preparing/managing the domain model is functionality and that may be exposed via many different outlets. Hiya… I disagree with your views on services. Services are great for all non-view preparation functionality. You should make controllers very thin like you say, but pushing too much functionality into domain classes is bad news, because even with logic related to a single domain class you may need to expose this functionality later as a SOAP, REST, XMLRPC or other service technology.

Our domain classes are not anaemic - we put functionality related to the class in there in our apps, but typically this is very minimal on the basis that anything that is not just for preparing/managing the domain model is functionality and that may be exposed via many different outlets.

]]>