Doubly linked business objects.

Doubly linked business objects.

Old forum URL:

wjcomeaux posted on Friday, January 18, 2008

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.





JoeFallon1 replied on Friday, January 18, 2008

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.



RockfordLhotka replied on Sunday, January 20, 2008

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...

Maqster replied on Monday, January 21, 2008

Hi Rocky,

you are talking a lot about designing objects per-use case basis. Do you have any examples on how you get the use cases down on "paper"?

I'm a little confused about the way one should get all the use cases down on paper before starting to develop their objects, my thoughts were that a use case consists of the end result of a UI. So I was thinking of prototyping the UI and then go for the objects. What do you think?

I would really appreciate an example of one or two use cases.

Best regards

JoeFallon1 replied on Monday, January 21, 2008

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.


Maqster replied on Monday, January 21, 2008

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?


RockfordLhotka replied on Monday, January 21, 2008

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.





From: Maqster []
Sent: Monday, January 21, 2008 9:08 AM
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 replied on Monday, January 21, 2008

Thanks Rocky, that was a good summary and gives me a good idea on how to use case my objects.

Best regards

wjcomeaux replied on Monday, January 21, 2008

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,

JonM replied on Monday, January 21, 2008

I think prototyping the UI first makes a lot of sense.  In the past I would build business objects and then try to figure out how to bind them to the UI.  This was a huge mistake causing me to rewrite many of the objects to fit with the UI.  Design your business objects so that they fit with how you want to interact with them from the UI not based on how the database is layed out.  Now with simple collections they may still be the same.

Copyright (c) Marimer LLC