Inviting some thought on Rocky's reply to razorkai

swegele posted on Monday, May 22, 2006

2 / 3 - From: RockfordLhotka Posted: 4/21/2006 9:43:00 AM

This isn't a supported approach really... What I do in such a case (because you have two different use cases here - just with a convenient navigation path from Company to CompanyAddress - not a parent-child relationship), is to have a GetAddress() method rather than a property. Public Function GetAddress() As CompanyAddress Return CompanyAddress.GetAddress(mCompanyId) End Function Notice that I DO NOT store this reference in an instance field - this is merely for navigational convenience. Don't confuse parent-child (containment) with navigation (using) relationships. Rocky   I have done a huge amount of what was recommended NOT to do up above...and I wondered if some of you experienced OOP guys could comment on this. My CEO wanted a design where you can access and edit a lot from one screen without a bunch of popups with separate apply buttons.  So we designed an object hierarchy that goes about 5 levels deep using many switchable objects in order to accomodate the one save / cancel button.   Project Tracker is designed to look at one thing...and edit related things in popups...not have the power of a related thing as a property on the object currently being edited.  I didn't know any other way to handle this problem of not being allowed to use popups and fairly frequent CRUD operations.  My app has one form that shows one main thing and all related things in grids organized in ExplorerBars.  It is a lot of power...but the objects have turned out to be harder to manage this way to be sure. Sean

   

DavidDilworth replied on Tuesday, May 23, 2006

I'd say that both approaches have merit to meet different requirements.

Clearly the requirement you have to build a very complex screen and have a whole bunch of objects that are editable/savable on the same screen means you have to build a complex business object.  That's what your use case is telling you.  And that's what your CEO wanted.

However, the other approach is equally right as it meets the requirements of easy to read code (i.e. Company.CompanyAddress), as well as having distinct processes to edit/update the CompanyAddress object separately from the Company object.  That's essentially what the Project Tracker example code demonstrates.

swegele replied on Tuesday, May 23, 2006

Thanks David,  it helps to hear from others about this issue.  I agree that both are right...just a matter of complexity and payoff.

I wonder if anyone has had success creating a flat ui that 'seemingly' edits one object fetch...but behind the scenes is actually following the 2nd approach you noted.  My gut says this is a UI problem that should be solved in the UI not in the business object.  If my objects really SHOULD be setup in a using relationship...then the UI needs to figure out how to hide that complexity right?

Sean

ajj3085 replied on Tuesday, May 23, 2006

I had something similar, although not nearly as complex.

I just finished a contact management system (which will soon grow itno much more).

The users wanted to enter the company and department which the contact belonged to, but they wanted it all on one screen.   Other requirements dictated that Company and department be their own tables in the database.  My problem was taht they wanted to enter any old company and department, without going to the other parts of the application to setup the company first. (Which is totally valid; they need to get all the data in as quick as possible).

What I ended up doing was having a company / department comboboxes which allowed free text.  If TextUpdate was fired (which is only the case if the user enters text NOT already in the Items for the combo), i used some tricker to set the in memory contact objects' department id property to an invalid value.  When both combo boxes were filled in, i could either set the DepartmentId to that of an existing department (if those chose one of the items) or to some fake (but valid) id.

When saving, i check the SelectedIndex properties, and if they are null i create a new company and or department before telling the contact to save.  It was much more complex to setup, but they seem happy with it, and it works pretty well.

Andy

RockfordLhotka replied on Tuesday, May 23, 2006

I think the answer lies in your use cases. It is absolutely the case that some objects exist primarily as data containers and for navigation. But those are responsibilities that should flow from the use case.

It is also certainly true that some parts of a "use case" are actually user experience artifacts, not business artifacts. A requirement that you use or don't use modal windows is a user experience artifact, and so (in general) should be solved by UI objects, while the underlying business objects continue to focus on the business aspects of the use case (which should be largely independant of the user experience).

A way to think about this is whether your business objects would work with a different user experience - to achieve the exact same business goal. If they can do that then your objects are probably pretty good.

That's not to say that they automatically trivialize the UI development effort. Which may mean creating extra UI objects.

There's another thread about wizard UI's. Many wizards cover just one use case, but some wizards have optional sub-flows that are actually separate use cases. But those use cases could be expressed in various types of UI, not just a wizard. So the wizard requirement is a user experience issue, not a business issue. So separating those concerns is important.

The right answer (imo) is to have a business object that matches the overall use case. Then you might choose to create one UI object per wizard panel. These UI objects are "wrappers" over the business object - each one providing a bindable view against the set of properties required by the specific panel. The idea being that you can still use data binding (against the UI object), without compromising the business object itself, which remains focused on the business use case.

While many forms can be created directly on top of business objects, that is not always true. The key is to keep the objects focused on the business, and potentially create intermediate UI objects to provide specialized views of the underlying objects for cases where the UI's requirements are substantially different from the straight use case.