Re: Repositories, package dependencies, and domain-flavoured exceptions
- From: "Nick Malik [Microsoft]" <nickmalik@xxxxxxxxxxxxxxxxxx>
- Date: Tue, 26 Jul 2005 07:02:01 -0700
I think I understand what you are trying to say.
Here's how I read your problem:
You are restricting the use of your "domain" classes in an attempt to get
strict adherance to seperating concerns (Kudos). However, you have a
situation where the strict rules of dependency are reversed, in that the
exception type itself has to be used by the "domain" class to generate an
error that the "action" classes can understand... without running afoul of
your enforcement mechanism.
(please correct me if I didn't get that right).
I can see a couple of practical alternatives:
a) Always return a customer. By that, I mean that a search that would
normally return "no customer found" would return a "null customer" that the
other classes can understand.
b) Refactor your calls just a little, so that you have a call that
determines if a customer exists (returning a boolean 'true' if it does)
while a second call gets the data.
c) Ask yourself: is "customer not found" really an exception? Sounds like a
normal part of processing to me. If that's the case, then it would be
normal for no customer to be returned, in which case, you could return a
NULL value and the caller would detect it as part of normal operations.
(sounds good on paper, but I really don't like this one... it makes the
calling code more complex. It's a preference thing).
Hope this helps,
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Jason Che-han Yip" <jcyip@xxxxxxxxxxxxxxxx> wrote in message
news:42e63237$1@xxxxxxxxxxxxxxxxxxxxxxxxx
>I figured this group will have some insights so here's my story...
>
> I have a Repository that will abstract the intricacies of retrieving a
> particular kind of Customer using an Account Number. It is possible that
> the Account associated with the Account Number is closed, or doesn't
> exist, in which case, no Customer should be returned.
>
> Question #1: Should this logic be part of the Repository?
>
> I had this logic in the Repository, however, we have JDepend (a Java
> package dependency tool) rules preventing references from "domain"
> packages to our "command" packages. The problem was that the Repository
> find method had AccountNotFound and AccountClosed exceptions in its
> signature. The Repository is in the "domain" package, the exceptions are
> in the "command" package.
>
> Question #2: Are Java packages really appropriate to be determining
> illegal package dependencies? I can accept that this might be a
> reasonable simplification.
>
> Most of the coordination of domain objects are done in command processors
> which is why, I presume, these domain-flavoured exceptions are in the
> "command" package. There are also Struts (Java request-driven web app MVC
> framework) actions that are used to add errors to the view depending on
> what kind of exception is thrown by the execution of the command. I
> suspect that some kind of generic handler could have been used as the
> exceptions all contain keys to the messages that should be displayed. In
> any case, we have another JDepend rule that prevents using "domain"
> package classes in "action" package classes. So I would be inclined to
> move these domain-flavoured exceptions to the "domain" package but this
> rule prevents me from doing so.
>
> Question #3: Should domain-relevant exceptions like AccountNotFound,
> AccountClosed be part of "domain" packages? And if so, should
> presentation packages be able to reference them in order to translate them
> into view-specific representations?
.
- Follow-Ups:
- Re: Repositories, package dependencies, and domain-flavoured exceptions
- From: Jason Che-han Yip
- Re: Repositories, package dependencies, and domain-flavoured exceptions
- References:
- Repositories, package dependencies, and domain-flavoured exceptions
- From: Jason Che-han Yip
- Repositories, package dependencies, and domain-flavoured exceptions
- Prev by Date: Re: Repositories, package dependencies, and domain-flavoured exceptions
- Next by Date: Re: Repositories, package dependencies, and domain-flavoured exceptions
- Previous by thread: Re: Repositories, package dependencies, and domain-flavoured exceptions
- Next by thread: Re: Repositories, package dependencies, and domain-flavoured exceptions
- Index(es):
Relevant Pages
|
