Hello again. Another day, another design need.
I have a design issue that I am having trouble coming to grips with.
I have a master object (let's call it Alpha) that handles an Editable list of Beta objects.
Each Beta object handles an Editable list of Gamma objects.
However, I have a use case that also dictates that Alpha has access to a list of all Gamma objects.
My first thought was to expose a property on Alpha called GetAllGamma and let that property create and return a list formed from all the Beta->Gamma objects. However, since Gamma is a child of Beta (and it should be) I can't create the Gamma list in Beta.
What's a good way to approach something like this? Basically I want a main form to list all Beta AND all Gamma objects. I want the Beta form to list all Gamma objects that correspond to the chosen Beta.
TIA,
Will
I think the final decision depends on whatyou plan to do with the lists. Do they have to stay in sync or not?
If they have to stay in sync I would probably use your initial approach and build the list in Alpha "on demand" using each Beta and its child collections of Gamm objects.
If you just need a Read Only List that matches what you started with I think I might create a new ROC and then fill it when Alpha is filled. The SQL would return all Gammas in one shot. It would be very fast to load it up.
Joe
Since you seem to be talking about two different forms, are you possibly talking about two different use cases as well?
Remember to design your objects on a per-use case basis.
Don't try to reuse objects across use cases until after you've done the per-use case design. After you've designed (on paper/whiteboard/whatever) the objects for each use case independently, then you can think about reuse.
Only reuse objects if their responsibility is an exact match between use cases. Or to put it another way, only reuse objects if you can reuse them without changing them. If you need to change a perfectly happy object from use case A so it fits into use case B then you've increased coupling and decreased maintainability - which is a net loss, since the only reason for reuse is to increase maintainability...
I tend to think of the UI screen as a use case. So after I prototype the UI, I then build the BOs necessary to make it function. It works well for me.
Joe
Like Joe, I tend to consider a UI form/page to be a use case –
though that isn’t always totally true. Sometimes a series of pages is a
use case (like a wizard, or x steps in a single process). But as a basic
starting point it isn’t bad.
But I always try to think about any use case from a “non-UI”
perspective too. The single biggest cause of artificial complexity in my experience
occurs when UI and business concepts get blurred. When business layer stuff leaks
into the UI, or UI stuff leaks into the business layer.
Data binding and CSLA’s model help keep business stuff out
of the UI – that’s been one of my primary goals all this time.
But keeping UI stuff out of the business layer is a little
harder, because it is often more subtle.
One tool I use to help avoid this pitfall is to start with the
UI-as-a-use-case, but then to think of the use case as a service API as well.
What if there was “no UI”, but just some WCF service? Am I putting
functionality into the business layer that is useless in the service setting?
If so, that functionality probably belongs in the Windows/Web/WPF UI, not in
the business layer itself.
I do this as a mental exercise, even if I have no plans for a
service interface.
Conversely, btw, I do the reverse if I’m building a
service interface. I always try to envision what a real UI would do on top of
the objects – trying to make sure I didn’t bastardize the object
model so it only suits a service API.
Rocky
From: Maqster
[mailto:cslanet@lhotka.net]
Sent: Monday, January 21, 2008 9:08 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Doubly linked business objects.
Thanks Joe, then I'm not totally of base. That's the way I
see it too.
Is their anyone out there that has a different approach?
/maqster
Thanks guys: That does clear it up a bit. I actually was designing use-cases from a UI page point of view. I know what I need on window 1 (Alpha object and interactions with it).
I think the load Gamma from Alpha when necessary approach works the best for me.
Thanks again,
Will
Copyright (c) Marimer LLC