Diff between service and model

[Dave Burns]

Looking through the examples, having read the relevant chapter in the CF Anthology book, can someone please help clear up what must be a simple thing: what is the intended difference between a model and a service? Understood that there are no single right answers but there must be a solid convention somewhere. Am I right that a model is just a simple bean with getters and setters but no smarts, i.e. business rules, and that the business rules tend to be embedded in the service object?

[Matt Quackenbush]

No, I would not agree at all with that definition/description.

A model is the whole of the business model.  It is *not* a single object.  And it is definitely not a glorified structure (a bean with getters/setters and no smarts).

Your business objects (which are independent objects that collectively make up the model) should be **very** smart.  They should be focused upon their specific task, or related tasks.  They should __not__ handle any tasks that are not specific to themselves.

The service layer, on the other hand, is what the controller layer talks to in order to retrieve business objects and/or get things done.  The service layer also coordinates the communication between business objects when the requested task (e.g. what the controller asks for) requires interaction with more than a single business object.

That is the 30,000-foot overview.  :-)

[Nathan Dintenfass]

I think when you're getting started it's also worthwhile to forget about
trying to make those things distinct from each other -- as you go it
will become more clear where and why to separate out "business objects"
from "services".

Sean had a great post the other day in which he admitted (gasp) that
when he first starts an app he often just shoves logic directly into
controller methods in order to feed some wire-framed views. Then, as
the scope and function of the application come into focus he can break
things out -- personally, I've seen far too many folks try to start "The
Right Way" only to end up with an over-complicated mess of code that
isn't actually helping them get the job done (and often just has
components that do little more than duplicate methods in another
component, all in the name of implementing these patterns).

Separating concerns is a generally good thing to do, but only when it
actually saves you time/effort/maintenance -- and many apps are small
enough that they can start with just controllers and services (or
skipping services entirely and just having the controller call out to
implementations of your business logic in the model).

Having several distinct tiers and doing dependency injection and the
like can be very powerful, but if these concepts are new I think it
behooves you to discover their purpose "bottom-up" rather than
"top-down" -- break things out as it becomes clear when it would be a
lot easier if you did.

Personally, I think given that FW/1 already gives you a nice way to talk
to services a fine way to start is to turn off implicit services, then
put your business logic into the services folder and use the service()
method, or (as I showed in a previous post) create a very lightweight
implementation of the beanFactory interface that FW1 expects and put
your singleton services inside of it - then call those directly in your
controller. If later it turns your model is complex enough and clear
enough that it warrants being broken out separate from your services you
can refactor into a separate model layer and have your services use
those methods instead.

YMMV, of course.

- Nathan D

> --
> FW/1 on RIAForge: http://fw1.riaforge.org/
>
> FW/1 on github: http://github.com/seancorfield/fw1
>
> FW/1 on Google Groups: http://groups.google.com/group/framework-one

[Matt Quackenbush]

+1 to Nathan's post.  :-)

[Dave Burns]

All helpful replies I guess but I'm still not clear. Is a service an abstract notion that, in a sense, aggregates multiples pieces of your model?  I learn best by example. Could someone supply a scenario where making a distinction between service and model was the right design decision?

[Matt Quackenbush]

Have you looked at any of the sample applications?  Pick any (or all?) of the MVC frameworks, open their sample applications, and work your way through the code.  In doing so you will find all kinds of scenarios.  :-)

[Dave Burns]

I have. That's why I posted this thread. I'm not being lazy and looking for someone to do the work for me.

[Matt Quackenbush]

I guess I am not understanding the question, then, because the samples are chock full of scenarios that show when to use each layer of the application.  Can you elaborate?

[Dave Burns]

Maybe it's easiest if I give my own example. Let's say I have a web-site where people can pay to be members. There's a sign-up form that they fill out where you collect the usual info about their name and address, etc., also their payment info like credit card number, and then info about the type of membership they want to buy. So, when they submit the form, how would you organize the code that should be executed? Is there one CFC in the /model folder per table, e.g. person.cfc, creditcards.cfc, membershiptypes.cfc, payments.cfc, etc. and then something in the /service folder called signup.cfc that takes the entire form and coordinates handing off specific tasks to the model CFCs? Or does that division of labor happen more at the controller level? Or am I completely off?

[Matt Quackenbush]

In your example, the request would be received by the controller.  It would then pass off the received data (e.g. the form values) to the service, which would then perform the magic of putting it all together.  And yes, the "magic" typically involves calling multiple objects that each handle their specific portion of the overall task.

As a quickie example, it might look something like so...

// controller
public void function doRegisterUser(rc)
{
     var user = UserService.registerUser(argumentCollection=rc);
     if ( user.hasErrors() == false )
     {
           // redirect to "success" page, or "control panel", or whatever is appropriate
     }
     else
     {
           // redirect back to the form page, passing along the errors
     }
}

// service
public any function registerUser(
        // arguments that you need, as appropriate
      )
{
     // create object(s) as necessary, populate them, validate them, save to db, etc
     return user;
}

Your description here is much, much, much more accurate than the one in your original post.  :-)

[Sean Corfield]

On Wed, Mar 2, 2011 at 9:48 PM, Dave Burns <goo...@burnsorama.com> wrote:
> Looking through the examples, having read the relevant chapter in the CF
> Anthology book, can someone please help clear up what must be a simple
> thing: what is the intended difference between a model and a service?

Which "relevant chapter" are you referring to?

> Understood that there are no single right answers but there must be a solid
> convention somewhere. Am I right that a model is just a simple bean with
> getters and setters but no smarts, i.e. business rules, and that the
> business rules tend to be embedded in the service object?

No, absolutely not. That would be a very procedural approach that left
you with dumb business objects - an anemic domain model.

In an MVC app, the Model is everything that isn't just "traffic cop"
logic (Controller) or View. Your application model includes a number
of (hopefully smart) business objects / domain objects as well as
services that orchestrate operations across multiple business objects
and perhaps provide a facade / API for the controller to use.

Make sense?
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

[Dave Burns]

> Which "relevant chapter" are you referring to?

Two actually: #20 exposing the service layer (Peter Bell) and #21, Beans, DAOs and Gateways (your own).

What you're saying makes sense if I'm learning what MVC is but I've used MVC for years. What's new to me is the notion of "service" as distinct from "model" so I was looking for use-cases that would help me understand the distinction and where I would put different types of code if I started making the distinction myself. I've read your comments about anemic domain models before and I agree with them. But if I need to implement a business rule and I'm trying to follow a general guideline about what goes in a model vs. service, is it accurate to say that things are pushed down as specific as they can go but no further? For example, a rule entirely specific to one bean gets implemented within that bean but a rule that requires knowledge across multiple beans goes in the service layer?

[Dave Burns]

> Your description here is much, much, much more accurate than the one in your original post.  :-)

Yeah, I try to strike a balance in online forums between being wordy enough to be useful and being too wordy in my initial problem statement that people don't read it. Guess I struck it wrong this time. :-)

So in your registerUser service function, you mention creation, population, and saving to db. That all seems clear to me as self-contained per bean. You also mention validation. Sometimes one is able to have the validation rules be entirely within a bean without knowledge of any other object (e.g. US zip codes have 5 or 9 digits). What about when validation requires "cross-bean" knowledge though? Not a great example but how about if we only accept Visa cards from certain US states? So I need to know info about both their CC and their address and these are stored in different beans. Should I put only that biz rule up in a service?

[Jamie Krug]

On Fri, Mar 4, 2011 at 7:46 AM, Dave Burns <goo...@burnsorama.com> wrote:

What's new to me is the notion of "service" as distinct from "model" so I was looking for use-cases that would help me understand the distinction and where I would put different types of code if I started making the distinction myself.

I believe this is an incorrect notion. I generally think of the service layer as part of the model, because it's generally tightly coupled with business/domain objects in your model. Sean often refers to services as having the job of coordinating interactions between different business objects, and this of course creates fairly tight coupling between a service object and a group of closely related business objects. If not part of your model, maybe think of a service layer as being the gateway to interact with your model, or a facade or API through which you can interact with your model. Another benefit of a service layer is a singular means to allowing interacting with your model in different ways (from controllers, via AJAX calls, exposing as REST or other remote services, etc.).

So, I'd say that business and service objects are the key ingredients of a model. I guess the data access layer is part of the model as well, but try to not let that influence design of the model in any way, since that's merely a means to persisting business object data, and it can be fairly well abstracted (virtually "invisible" or inconsequential to model design) with something like ORM.

I was going to try to summarize some key points that I've learned, but it's such an art, and it's so difficult to describe without lots of caveats and real examples :) I do know that there have been some past discussions on this subject, on this list, so let me try to find some helpful posts. Here are just a few good threads; each includes some very good points and discussion...

https://groups.google.com/d/topic/framework-one/ZZr1rLjONgM/discussion

https://groups.google.com/d/topic/framework-one/2GIm6tV3hR0/discussion

https://groups.google.com/d/topic/framework-one/mFycuV_PgHY/discussion

I'd actually like to highlight a few key points from this last link, made by Sean:

I'd strongly recommend not getting into this whole bean + DAO + gateway + service approach. You'll create a lot more objects than you need and you'll likely end up with an anemic domain model (a 'struct' for a bean and all your logic elsewhere). 

Here's what I recommend: 

- a bean per entity (nothing controversial there) 

- a gateway for each group of related entities - that handles both CRUD *and* aggregate queries 

- a service for each distinct area of your application 

The services and gateways do not need to match up (they often will - they just don't have to).

...

The key is to keep as much business logic as appropriate in your domain objects so that services act only as coordinators for operations that must span multiple domain objects.

HTH!

Jamie

[Dutch Rapley]

+1 to what Jamie said. Along the lines of what Jamie said, I use my service layer to manage interactions between all my business objects. Something I would recommend doing is getting familiar with using a bean factory. While the topic can be a daunting one, using a bean factory (in the context of FW/1) makes it really easy to wire business objects into your services.

-Dutch

--

[Sean Corfield]

On Fri, Mar 4, 2011 at 12:46 PM, Dave Burns <goo...@burnsorama.com> wrote:
> What's new to me is the notion of "service" as distinct from
> "model" so I was looking for use-cases that would help me understand the
> distinction and where I would put different types of code if I started

I've no idea what you mean. An application has a model. That model
includes services, business objects, the data access layer and so on.

> rule and I'm trying to follow a general guideline about what goes in a model
> vs. service, is it accurate to say that things are pushed down as specific

That question makes no sense. The service is part of your model
anyway. The business rules live _somewhere_ in your model.

> as they can go but no further? For example, a rule entirely specific to one
> bean gets implemented within that bean but a rule that requires knowledge
> across multiple beans goes in the service layer?

That's purely mechanics: a rule that applies across multiple business
objects generally has to live outside any specific business object -
it's orchestration, by definition. (technically you could designate
one business object as 'owning' the rule but the that object would
need to access / interact with the other object somehow)

Does that help?

[Dave Burns]

Sean, Jamie, Dutch, Matt -

All helpful replies and my mental model of how it all fits together is now much improved. If the questions made no sense, it may help you to understand where I was coming from: when I look at an example, say, the userManager example for FW/1, I see subdirectories for /model, /views, and /controllers - all familiar concepts. But then I saw /services as a peer directory to /model which threw me off. So, given what you have all said, would a clearer org (at least conceptually) be:

/model/services/
/model/individualbizobjects/ [not that I'd call it this but you get the point]
/model/dao/ [if you're not using ORM]

[Sean Corfield]

On Fri, Mar 4, 2011 at 6:22 PM, Dave Burns <goo...@burnsorama.com> wrote:
> /model/services/
> /model/individualbizobjects/ [not that I'd call it this but you get the
> point]
> /model/dao/ [if you're not using ORM]

If you are explicitly managing / calling services directly from your
controllers - i.e., not via the fw.service() method - then, yes, that
structure makes sense.

The top-level services/ folder is purely a convention / convenience
for FW/1 to auto-discover and instantiate service CFCs for you for
implicit calls to services.

FWIW, with DI/1, you'd be able to use your directory structure
(although the convention there is /model/beans for the transients :)
and just point DI/1 to the /model folder and have it auto-discover,
instantiate and inject your singleton and transient objects.

[Jamie Krug]

Here's another post from Sean that I tagged:

https://groups.google.com/d/msg/framework-one/iNmKrJz2Q-M/WFztkkbnSS8J

My directory structure was nearly identical to what Sean outlines there, but I also liked the idea of the thirdparty/ directories. In any case, note the app/model/beans/ and app/model/services/ sibling directories--both within the model directory.

Best,
Jamie

[Dave Burns]

Jamie - All great links and I just reread them. I remember that I'd read them all before but it's very useful to review them now with different context and different questions in mind. Thanks!

[Peter Bell]

On Mar 4, 2011, at 3:56 PM, Jamie Krug wrote:

On Fri, Mar 4, 2011 at 7:46 AM, Dave Burns <goo...@burnsorama.com> wrote:

What's new to me is the notion of "service" as distinct from "model" so I was looking for use-cases that would help me understand the distinction and where I would put different types of code if I started making the distinction myself.

I believe this is an incorrect notion. I generally think of the service layer as part of the model, because it's generally tightly coupled with business/domain objects in your model. Sean often refers to services as having the job of coordinating interactions between different business objects, and this of course creates fairly tight coupling between a service object and a group of closely related business objects.

Domain Driven Design has some good patterns around this. Check out the pattern summary on domaindriven.org. You're looking for the implementation level patterns - especially aggregate and value object.

Best Wishes,

Peter

[Patti]

I think a link to this topic would be at home on the "Helpful Links : Some Interesting discussions on Google Groups" page at GitHub

[Sean Corfield]

Good idea Patti - I've added the link. Thank you.

On Wed, Jun 22, 2011 at 8:28 AM, Patti <greym...@gmail.com> wrote:
> I think a link to this topic would be at home on the "Helpful Links : Some
> Interesting discussions on Google Groups" page at GitHub
>

> --
> FW/1 on RIAForge: http://fw1.riaforge.org/
>
> FW/1 on github: http://github.com/seancorfield/fw1
>
> FW/1 on Google Groups: http://groups.google.com/group/framework-one
>

--

Sean A Corfield -- (904) 302-SEAN

An Architect's View -- http://corfield.org/

World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)