Group,
Up front I have to admit to being a novice when it comes to OOP design.
I'm trying my best, but i'm having difficulty figuring out which classes to inheret, and thus a satisfactory object model for this hierarchial data i have.
Using a folder structure in a filesystem as an analog. I have one or more folders at the top which may contain one or more folders, which may each contain one or more folders, and so on.
Do i have a case then where both Folders and Folder need to be switchable?
I'll freely admit if i'm misuderstaning something, but it seems to me that the top level collection of folders is initially a Root and a Parent and is editable. A given folder within that collection is thus a child and is editable, but is also a parent for a Folders collection which then suggests that "Folders" be switchable, or that I at least have a SubFolders object that derives from Folders that's defined as a child.
Any guidance would be appreciated.
The filesystem scenario is one of the few where switchable does make sense.
But there are few business use cases that actually match a filesystem in reality. There are many data relationships that look similar, but very few usage scenarios that are similar. And your objects should be designed to match usage scenarios, not data relationships.
Rocky,
Thanks for the reply. As I say I'm still sort of finding my feet with regard to OO design. My background is in SQL so structuring the data and writing procedural code is my strength, and I have no formal training in C# despite the fact i've been "coding" for the past 4+ years. This is why I have a hard time clearly defining an object model.
I realize this isn't CSLA specific, but I appreciate any comments. So this is what I perceive my usage scenario to be, at least as I understand the concept:
This is an application for a military client. The client is responsible for tracking certain information about commands. Administrators must be able to add, update and delete a command (subject to certain business rules). Each command may be the parent command (their term) of any number of subordinate commands.
The application must be flexible enough to allow administrators to reassign (read move) a command from under it's current parent to any other command, to include the top (root level). (This suggests a treeview in the UI)
Users who will be responsible for entering data can be associated with one or more commands and will require visibility of all subordinate commands. Thus in the case of a commander who is associated with two commands there will be more than one top level command displayed in the interface.
So for me it would seem that the Commands collection (editable) is a root collection which is a parent of one or more other child Command objects (editable) which are subsequently parent to a child Commands collection.
Also, from a data handling efficiency perspective it would seem to make sense to me to query for all commands below any selected command, returning one set of data (in the case of the administrator the entire tree, and in the case of the user from his command(s) down). So i'd be passing the entire DataReader through the object hierarchy, and looping through it to build a subordinate Commands colleciton vice making repeated round trips to the db.
Opinions? I'm looking for validation of my thought process, so if I'm way off base, I appreciate any education you can offer.
You are potentially describing 2-3 use cases.
You might consider using the tree UI metaphor, but binding it to a set of objects designed around use case #3. In other words, they might be "read-only" to a large degree. In fact, they might be less business objects than UI objects.
When the user clicks the option to add a command, you'd use a CommandEdit object for that purpose. A different object from the display objects, because this is a different use case. Once the add is complete, the view objects could handle an event so they know there's the need to update the view accordingly.
Similarly, when the user drags-and-drops a command beneath a different command, behind the scenes this may execute a CSLA Command object to do the move in the database. When that move operation is complete a similar event to the view object(s) would indicate to refresh the view.
Refreshing the view doesn't necessarily mean reloading all the data. As long as enough information is passed via those events, the view should be able to update itself based on the events alone.
Rocky,
Thank you so much for the education. You've given me some really good information and suggestions to digest.
Since, as I mentioned, I'm pretty weak on OO design, do you have any recommendations for good reference materials?
Regards,
Todd Hicks
Some of my favorites:
David West: Object Thinking
Eric Evans: Domain-Driven Design
David Taylor: Object-Oriented Technology: A Manager’s
Guide
GoF: Design Patterns
Martin Fowler: Patterns of Enterprise Application Architecture
Hohpe/Woolf: Enterprise Integration Patterns
Rocky
From: electronjockey
[mailto:cslanet@lhotka.net]
Sent: Monday, July 02, 2007 8:05 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Hierachical model - case for switchable
Rocky,
Thank you so much for the education. You've given me some really good
information and suggestions to digest.
Since, as I mentioned, I'm pretty weak on OO design, do you have any
recommendations for good reference materials?
Regards,
Todd Hicks
Copyright (c) Marimer LLC