Best practices with services and controllers

[barnesjd]

I'm a well seasoned J2EE developer who is new to Spring, Grails, and Groovy.  I'm working my way through the Mastering Grails trail and playing with my own application.  

I'm curious what is the best way to separate controllers and services in Grails.  For example, in my application I have a user-entered object that will contain a large text field (we'll call it UserInput).  I want to parse the text in this object to create components that I can programmatically manipulate, build forms, etc apart from the details of how the user entered the text (we'll call them ThisComponent and ThatComponent).  So this is my domain class:
UserInput:
    String text
    ThisComponent c1
    ThatComponent c2

(Side note: I want to persist both the raw user-entered text and the components that I parse out.  On one hand this is redundant, but I want to be able to correct the components as necessary when mistakes are made parsing the original text)

In my controller, I currently have the generated create() method.  The user is able to enter text and persist without any problems.  But where should I insert my service which will parse and create the component objects?  I'm not sure if the service should create and parse, or if I should leave the creation in the controller and have the service perform an update on the object.

Any opinions?

[Roberto Guerra]

I use the following rule: If i will ever need to reuse the logic somewhere else, I send it to the service. If it is something that fits in a rich domain class, then I prefer to place it in there. Typical example, a getAge() method in a Person domain. If it doesn't fit in a domain, I place it in a service.

On Wed, Feb 22, 2012 at 10:32 AM, barnesjd <[hidden email]> wrote:

I'm a well seasoned J2EE developer who is new to Spring, Grails, and Groovy.
I'm working my way through the  http://grails.org/Tutorials Mastering Grails
trail  and playing with my own application.

I'm curious what is the best way to separate controllers and services in
Grails.  For example, in my application I have a user-entered object that
will contain a large text field (we'll call it UserInput).  I want to parse
the text in this object to create components that I can programmatically
manipulate, build forms, etc apart from the details of how the user entered
the text (we'll call them ThisComponent and ThatComponent).  So this is my
domain class:
UserInput:
   String text
   ThisComponent c1
   ThatComponent c2

(Side note: I want to persist both the raw user-entered text and the
components that I parse out.  On one hand this is redundant, but I want to
be able to correct the components as necessary when mistakes are made
parsing the original text)

In my controller, I currently have the generated create() method.  The user
is able to enter text and persist without any problems.  But where should I
insert my service which will parse and create the component objects?  I'm
not sure if the service should create and parse, or if I should leave the
creation in the controller and have the service perform an update on the
object.

Any opinions?

--
View this message in context: http://grails.1312388.n4.nabble.com/Best-practices-with-services-and-controllers-tp4410927p4410927.html
Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

--
The Journey Is The Reward.

[barnesjd]

Thanks Roberto!  I typically think of domain classes as only appropriate for persistence.  I've not thought of creating a "rich" domain class as you called it.  I'll have to give that some thought.

[Octavian Covalschi]

Usually when people are moving to a new technology stack they tend to think in their previous/other technologies they are used to... 

So, for me at least, it makes sense as well to put some flavor into domain class, such as getAge() instead of someService.getUserAge(user) or UserUtils.age(user).  Having those additional methods would make code cleaner and you'd be able to use them inside your views (GSP files)

Just my 2 cents...

On Wed, Feb 22, 2012 at 4:55 PM, barnesjd <[hidden email]> wrote:

Thanks Roberto!  I typically think of domain classes as only appropriate for
persistence.  I've not thought of creating a "rich" domain class as you
called it.  I'll have to give that some thought.


--
View this message in context: http://grails.1312388.n4.nabble.com/Best-practices-with-services-and-controllers-tp4410927p4412091.html

Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Roberto Guerra]

This is a good read. Might give you some ideas:

http://martinfowler.com/bliki/AnemicDomainModel.html

On Wed, Feb 22, 2012 at 5:13 PM, Octavian Covalschi <[hidden email]> wrote:

Usually when people are moving to a new technology stack they tend to think in their previous/other technologies they are used to... 

So, for me at least, it makes sense as well to put some flavor into domain class, such as getAge() instead of someService.getUserAge(user) or UserUtils.age(user).  Having those additional methods would make code cleaner and you'd be able to use them inside your views (GSP files)

Just my 2 cents...

On Wed, Feb 22, 2012 at 4:55 PM, barnesjd <[hidden email]> wrote:

Thanks Roberto!  I typically think of domain classes as only appropriate for
persistence.  I've not thought of creating a "rich" domain class as you
called it.  I'll have to give that some thought.


--
View this message in context: http://grails.1312388.n4.nabble.com/Best-practices-with-services-and-controllers-tp4410927p4412091.html

Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

--
The Journey Is The Reward.

[xmly]

I put everything related with one domain into domain class.

The logic involved with several domain class in to service layer. 

On Wed, Feb 22, 2012 at 6:45 PM, Roberto Guerra <[hidden email]> wrote:

This is a good read. Might give you some ideas:

http://martinfowler.com/bliki/AnemicDomainModel.html

On Wed, Feb 22, 2012 at 5:13 PM, Octavian Covalschi <[hidden email]> wrote:

Usually when people are moving to a new technology stack they tend to think in their previous/other technologies they are used to... 

So, for me at least, it makes sense as well to put some flavor into domain class, such as getAge() instead of someService.getUserAge(user) or UserUtils.age(user).  Having those additional methods would make code cleaner and you'd be able to use them inside your views (GSP files)

Just my 2 cents...

On Wed, Feb 22, 2012 at 4:55 PM, barnesjd <[hidden email]> wrote:

Thanks Roberto!  I typically think of domain classes as only appropriate for
persistence.  I've not thought of creating a "rich" domain class as you
called it.  I'll have to give that some thought.


--
View this message in context: http://grails.1312388.n4.nabble.com/Best-practices-with-services-and-controllers-tp4410927p4412091.html

Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

--
The Journey Is The Reward.

[barnesjd]

Thanks for the insight, everyone.  I really like the article Anemic Domain Model.  My J2EE background has made me this way.  I tend to make domain classes that are nothing more than structs.  

Can the domain objects have transactional methods in Grails?