Hi all,
I have just started looking into Csla, and have a question about how I should handle this scenario.
Let's say I have a root class called Job.
Then let's say that the Job class will have a collection of another class called Rule.
The Rules on the Job need to be editable.
The Rules also need to persist independently of Jobs so that a user can add existing Rule objects to their Job.
So, my question then becomes, is the Rule class a child object, or a root object, or do I need to make two different Rule classes or something completly different?
Does anyone have an example of a scenario like this?
Thanks for any help :)
P.S I have the 2005 C# book sitting in front of me too, so if anyone knows where this is covered in the book, that would be great too.
This is a common (perhaps the most common) type of OO design question.
The thing to remember is that objects are defined by behavior, not by data. Moreover, they should be defined by their role - a single responsibility - within a specific use case.
So you are describing two different use cases. One use case has the user adding/editng a Job and associating Rules with that Job. Another use case has the user adding/editing Rules.
Notice how the two "Rules" concepts are not the same. In the first case the concept is an association, while in the second case the concept is data editing.
In that first use case, what you really have is a JobEdit object with an AssociatedRules collection of AssociatedRule objects. In the second use case you have a RuleEdit object (and almost certainly a RuleList read-only list and RuleInfo read-only object).
Thank you so much for the replies. I am sitting here looking over your project tracker example, and was about to dive deeper into it.
I was just noticing in the conclusion of Chatper 6 that you described the project as having a requirement of maintaining a list of projects, a list of resources, and then assigning resources to the project (assuming the resources themselves are editable also).
This sounds exactly like what I want to do, except in my case it is a list of jobs, and a list of rules that can be assigned to jobs.
My next question would simply be, should I look at the project tracker code now to get more answers on how to do it, other than your response that helped me also :)
Or, is rsbaker's reply(thanks rsbaker) the way I would need to implement it?
The question is all about the intended use case, or user story, or user experience - whatever you'd like to call it.
If the user edits Job and Rule information on one screen, as part of one task, then you'd probably have a JobEdit with Rules with RuleEdit.
If the user edits Job information and associates existing Rule information (which is what you indicated), then my previous post is probably more accurate.
I'm sorry if it is a little hard for me to explain, I just started a redesign of this project, and at the same time started reading your book. And of course it all has to be done in two weeks heh :)
What I would like, would be to have a tree view with the job as a root node, and associated rules as child nodes.
I would then like for the user to be able to drag existing rules from a panel to the job and have that assign those rules to the job.
I would then also like for the user to be able to select a rule node in the tree and edit the rule irself in a workspace panel.
When the user edits the rule in that fasion, it should update that rule for all jobs if they so choose, or create a new rule with the changes.
I guess a similar example, related to your project tracker, would be if your projects were shown in a tree, and had associated resources shown as child nodes.
Then you would also be able to edit resources just by selecting the resource in the tree and showing a resource editor, and then having the changes update the resource for all projects.
To me, this seems like the rules/resources would be editable root objects, and the jobs/projects would also be editable root objects, but at the same time the rules/resources are childs of the job/project.
I think your first response, and me thinking it out, sounds like I do indeed need separate classes, but this being my first time to design business objects the right way, I would love to get it right :)
Or maybe instead of different classes, I just need a propety on the job object that is a collection of assigned rule IDs?
Ahh, there’s a thread about something like this from
perhaps 1-2 months back.
The best overall solution for a treeview scheme is to use a set
of read-only lists and objects to populate the treeview control.
Then as the user selects operations on nodes from the treeview,
load editable objects for use in the work region of the form. The treeview isn’t
your use case, it is the menu into the use cases – and the use cases
exist in the work region (for the most part).
When the editable objects save themselves, they can notify the
read-only root object, which can bubble the notification down through the tree
so it can be handled by the appropriate read-only object – which then
updates itself (so it isn’t completely “read-only”, but isn’t
editable by the user).
Rocky
Awesome!
One last question and I will leave you alone. Is a scenario like this, or something close to it covered in the book? I will search in the meantime for the thread you mentioned.
On a side note...
Thanks a ton Rocky. I would just like to say that your framework, and the logic you used to build it, is some of the most ingenious thinking I have ever seen. I just have to wonder how much work experience you had to go through to figure out how to design projects so well :)
If I had only been taught this stuff in college, or even had a meantor with this kind of experience...
And on top of that, my first day to the forums and I get help from the author himself. Could not have had a better experience.
Thanks!
Is this perhaps the thread you mentioned? Just posting it to help anyone that comes across the same subject in a search :)
I appreciate the kind words, thank you.
Unfortunately this scenario is not covered in the book, and I don’t
have a demo that shows it (though it is a good idea for a demo :) )
Rocky
Copyright (c) Marimer LLC