ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Benedict <paul4chris...@yahoo.com>
Subject Re: Too many methods on a service object
Date Sat, 12 Nov 2005 00:13:36 GMT

Some comments on your worsd:

>>Suppose I have a Person and an Address object. Normally there would be one or more
methods on the service object

In Java, the popular method is to create a real object and make instance calls. ALot of people
have taken hold to the Spring Framework, which will instantiate singletons of whatever class
then you use those during your app. So here, use singleton instance objects.

> My colleague brought up the point that this can get out of hand (i.e.
> you start getting _a lot_ of methods):

I guess it is what level of tolerance you have. If you are realistic about a situation, you
end up having many methods that all represent real business cases, but I have to say some
of those
methods below look seriously wrong. There is no reason to have a GetManyWithNonNullAddresses
then a GetManyWithNonCityAddresses method; you should make the choice to return ALWAYS full
objects at least one object-depth deep. So, in your case, always return addresses if they
are one
depth in the object graph. When objects get more complicated and you are returning too much
you will not use, this is where you refactor into nested objects. Here, you can then craft
to return how many nested objects you want or use iBATIS' autoproxying to run SELECT statements
the nested objects you later hit. I don't have your problem here, and yours can be effectively

> My argument was that those methods wouldn't be written until they
> needed to be used. In other words I wouldn't just be making up random
> methods and never use them

Do not expose any methods your clients will not need. Make the rest private until there is
business case.

> Again, that's not the best example. Imagine the case where I have to
> call through to many service objects until I get my final result. 

There's nothing wrong with service objects relying on other services. However, your problem,
again, goes back to your object graph. If you model your objects properly, you will understand
that when you SELECT for an object, you take as many levels deep as you think you will need....
But at least one level deep for simple properties.

> Some other questions I was stumbling on: should the service layer be
> defined through interfaces?

Absolutely. All service objects should be an interface that is implemented. Java requires
this to
do auto-proxying.

> Should the service layer throw its own ServiceExceptions or just pass
> through the data layer's exception? What happens if the service layer
> just throw up the data exceptions to the presentation layer? The

No. The service layer should not create a wrapper exception just for the sake of it. The Spring
Framework philosophy -- which is pretty popular -- is to let all runtime exceptions bubble
to the
top and only throw checked exceptions if the client can actually recover from it. I allow
all my
exceptions to go through the roof and then I have a webapp configuration which handles the
exceptions for me. BTW, I did do EXACTLY what you're asking and it turned out to be a bad
yes, you will have one nice exception to handle but it's a completely useless feature. Only
custom exceptions if they have real business meanings (UnauthorizedException,
StaleObjectException, etc.) and real business decisions can be made from them. Otherwise,
let them
go to the sky.

-- Paul

Yahoo! Mail - PC Magazine Editors' Choice 2005 

View raw message