Switchable objectOld forum URL: forums.lhotka.net/forums/t/8358.aspx
MTmace posted on Thursday, January 14, 2010
I would like to edit some of an object's, the most commonly modified, properties in a grid.
Then I would like to edit it's other properties when someone selects the object.
I thought this would be an EditableRoot object. However since I need to edit it in a list I think it needs to be an EditableChild object.
Is this a good use for a switchable object or is there a flaw in my object design?
rxelizondo replied on Thursday, January 14, 2010I think that the scenario you are describing is very valid for a switchable object. As long as your object behavior is *identical* whether it’s posing as a root or as a child then I think you are good.
Just note that Rocky has stated before that having switchable objects it’s usually a bad thing. But I believe that it all goes back to people designing the switchable object to have different behavior for the two different roles.
I may be wrong about this so I hope others chime in and give their opinion. I have never coded a switchable object so my experience with them is zero :(
JonnyBee replied on Friday, January 15, 2010
If you have a Datagridview and details editing controls - all in the same Form you should databind all controls to the same
bindingsource. The bindingsource has a CurrencyManager that keeps track of the "current item in list" and enables databinding for both listcontrols (complex databinding) and details controls (simple databinding).
A Switchable object can be a Root or Child object depending on which static factory method you use to get an instance of the object (and if that method calls MarkAsChild). Once you have an instance - there is no way that you should be switching from Root to Child or back.
As always - I recommend to read the excellent FAQ documents on http://www.WindowsClient.net
and DataBinding FAQ
. Both FAQ also comes with sample code.
MTmace replied on Friday, January 15, 2010
Thanks for all the input I will look into the currenyManager.
If I can bind the "detail" control to the same object that is selected in my grid that should work.
So the correct object type should be EditableChild since the list will be marked as dirty even if the object was modified out side of the grid (in the detail control).
rsbaker0 replied on Friday, January 15, 2010We have a set of low-level BO's that map fairly closely to the database tables (done because this project is a direct translation of a previous VC++ 6.0 application and this simplified the translation), and these BO's seem to be quite comfortable being either root or child.
When we started this, the current CSLA version was 2.1 and there was seemingly almost no difference between a root and child other than the IsChild flag value, so we didn't see any problem doing this.
Now there is a child data portal, object factory, etc. that have since been added. We've upgraded as far as CSLA 3.5, but we haven't changed to use those features, so I can see how there might be a little more handling the switchability if you wanted to use the new additions.
ajj3085 replied on Friday, January 15, 2010
But I believe that it all goes back to people designing the switchable object to have different behavior for the two different roles.
Well, that's pretty much the argument against it. Different behavior due to different use cases, so a switchable object makes your design more fragile. I think this goes against the Single Responsiblity Principal.
Copyright (c) Marimer LLC