Methods in domain classes

[graham-2]

As a beginner... I notice that there are few examples (actually no non-trivial ones that I could find) which feature methods in domain classes, and all of the processing is carried out in the controllers. Is there any reason for this ?

In other OO situations it would be the case that the various classes would contain methods for the processing. For example one aspect of the project that we're working on is invoice generation and I'd probably have an 'addInvoice' method (actually it could be a method on the client) that would calculate and save an invoice. In grails would this function tend to be in a domain class or simply a part of the controller ?

graham

[Tomas Lin]

I think the reason for this might just be that the Domain Classes
correspond to MVC Models, and it doesn't make sense to add too much
logic in your models. The exception might just be the beforeInsert and
beforeUpdate methods that allow you change the mapping into a database
of your domain classes.

One of the beautiful things about Grails is the dynamic methods
available to domain classes, for your purpose, you don't need to
define an AddToInvoices method since it gets created dynamically (
http://grails.org/doc/1.0.x/ref/Domain%20Classes/addTo.html ).

I would also refrain from adding any or too much logic to your
Controllers, you should actually put all this processing in your
Services class. For our projects, we have found that changing the
Controller makes later changes to the Controller Template very
difficult to put back.

On Sat, Jul 5, 2008 at 8:50 PM, graham-2 <gr_grails@...> wrote

>
> As a beginner... I notice that there are few examples (actually no
> non-trivial ones that I could find) which fure methods in domain classes,
> and all of the processing is carried out in controllers. Is there any
> reason for this ?
>
> In other OO situations it would be the case that the various classes would
> contain methods for the processing. For example one aspect of the project
> that we're working on is invoice generation and I'd probably have an
> 'addInvoice' method (actually it could be a method on the client) that would
> calculate and save an invoice. In grails would this function tend to be in a
> domain class or simply a part of the controller ?
>
> graham
> --
> View this message in context: http://www.nabble.com/Methods-in-domain-classes-tp18297914p18297914.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
>
>
>

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

    http://xircles.codehaus.org/manage_email

[Richard M]

Graham,

I'm a relative noobie here too. I supposethe reason you are not seeing much
richness in the domain classes you see could be:

1) They are examples.
2) One of the driving reasons for using Grails is because you need to move
quickly. Right, or wrong, you may tend to not do as much design as you maybe
should - which causes lots more logic to end up in the controllers, when it
might be better put in either the domain class or (as another reply
indicated) in the service classes.

I find it hard to believe you would not want to add the richness of
expression to your domain objects - where it makes sense. In my use of other
more traditional Java frameworks, you actually shied away from this in some
cases because you were trying to keep your persistence technology out of
your domain classes. With Grails, you've already bitten that bullet - so I'm
not sure there's anything wrong with domain methods that might (for example)
use a dynamic finder to query related objects.

Just my two cents - hope it helps

 - Richard

> From: graham-2 <gr_grails@...>
> Reply-To: "user@..." <user@...>
> Date: Sat, 5 Jul 2008 17:50:27 -0700 (PDT)
> To: "user@..." <user@...>
> Subject: [grails-user] Methods in domain classes
>
>
> As a beginner... I notice that there are few examples (actually no
> non-trivial ones that I could find) which feature methods in domain classes,
> and all of the processing is carried out in the controllers. Is there any
> reason for this ?
>
> In other OO situations it would be the case that the various classes would
> contain methods for the processing. For example one aspect of the project
> that we're working on is invoice generation and I'd probably have an
> 'addInvoice' method (actually it could be a method on the client) that would
> calculate and save an invoice. In grails would this function tend to be in a
> domain class or simply a part of the controller ?
>
> graham
> --
> View this message in context:
> http://www.nabble.com/Methods-in-domain-classes-tp18297914p18297914.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
>
>
>

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

    http://xircles.codehaus.org/manage_email

[graham-2]

Ah, thanks for bringing me back to earth...I'm quite happy with MVC but this is the first project that we've had that is MVC from the ground up. And we've been learning Groovy/Grails at the same time so the effort of the latter has rather distracted from the underlying MVC-ness of the package

I must admit that we haven't really got to Services yet - something  to read up on later today. (I note "the Grails team discourages the embedding of core application logic inside controllers..." - obviously I hadn't got to that section ...)

However your comment re. addTo does bring up another question that I was going to ask, but I'll start a new thread for that.

graham


I think the reason for this might just be that the Domain Classes
correspond to MVC Models, and it doesn't make sense to add too much
logic in your models. The exception might just be the beforeInsert and
beforeUpdate methods that allow you change the mapping into a database
of your domain classes.

One of the beautiful things about Grails is the dynamic methods
available to domain classes, for your purpose, you don't need to
define an AddToInvoices method since it gets created dynamically (
http://grails.org/doc/1.0.x/ref/Domain%20Classes/addTo.html ).

I would also refrain from adding any or too much logic to your
Controllers, you should actually put all this processing in your
Services class. For our projects, we have found that changing the
Controller makes later changes to the Controller Template very
difficult to put back.

[Brad Whitaker]

There have been very similar discussions on this topic in the past. Here are links to a couple of them:

http://www.nabble.com/RE%3A-Where-do-we-put-our-business-logic--td15609839.html

http://www.nabble.com/Does-Grails-encourage-a-bad-M-C-split-in-MVC--td14713355.html

I have an OO and DDD background and I still haven't settled on a "best" way to use an OO and DDD approach with Grails.