views:

131

answers:

1

I'm not positive I have the right architecture for this problem. Let's say I have a Person object that has 1 or more Attribute objects associated with it. For the interface, I have a list of Person objects, a Person view, and another control with tab pages that represent each Attribute object associated with that person. How would an MVC architecture behind that be constructed?

Currently, I have a single 'model' for a Person that has a list of Attribute models. I have a controller for the view, and then I was going to make a controller for the AttributeView that would have sub-controllers for each Attribute attached to each Attribute model in the Person model... I think I can handle all the appropriate interactions with that architecture, but I'm not sure that it's the best implementation. Does that sound reasonable, or is there a better way to tackle this?

Thanks!

A: 

If it was me, I wouldn't bother having the main controller know about the sub-controllers for the attributes; I'd make that connection at the view level instead. So you'd have a PersonView that knows how to construct AttributeViews (passing in AttributeModels to them) -- or has a handle to a factory that knows that -- and the AttributeViews would know how to construct AttributeControllers.

Depends a bit on what you're trying to do, though. Like, do you need to be able to commit / roll back changes to an AttributeModel without actually committing those changes to the Person? Do you need to roll back changes to the Person as a whole? If the user selects a different Person in the list, do you need to do some validation before committing the changes, or to prompt them to save changes before switching Persons? Stuff like that is where the mess is likely to be.

David Moles
That second part is exactly where my mess is. Validation for the entirety of the Person object. So far the approach I chose seems to be working out ok, but we'll see how things end up working out. Thanks for the response!
genki
I've found a listener-based validation architecture works well in this kind of situation -- so the attributes would validate themselves, the person would listen to changes in the attribute validity and do any additional validation (e.g. combinations of attributes), and the list controller would listen to changes on the person. (Whether the validation happens on the models or the views depends on whether you want to commit invalid changes to the model -- which works fine, but in that case you want to be working with a copy of the model rather than the original.)
David Moles
That sounds about right. I'm definitely working with copies, basically I have stored objects ('config') and then the actual model objects that I use in the GUI, so changes to the model aren't actually 'saved' until they're written to the config.
genki