views:

70

answers:

1

So I have a structure like this:

Widget:
  Component 1:
  Component 2:
  Component 3:
  ...
  Component n:

I'm building an ASP.NET MVC web app that as part of its functionality will allow a user to create a Widget object and assign Component objects (which have a number of properties) as "children" of the Widget object. Users might have no Components or might add 50. In addition, they may edit a Widget object and arbitrarily remove or change Component properties.

Everything in the application is working but I'm not happy with the way this is structured. On Submit currently, I submit all Components with ALL their properties. I delete all components currently associated with this Widget and then enumerate over each Component and re-add it.

...But I'm not happy with this solution. For some Widgets with a massive amount of components (say 500) this process can be time consuming even if the user only changed one component. But the alternative (tracking Creates/Updates/Deletes on a per Componenent basis) seems really painful to build.

I'm sure that I can do this better, so I'm interested in knowing what sort of patterns can be applied to solve this problem (generally speaking) and particular in the context of web applications.

+1  A: 

Why is tracking the Create/Update/Delete so much harder? Take a look at my response to a similar question about finding the differences between what is in your repository and what is being posted back. Provided each Component has a unique ID (which it sounds like it does), it shouldn't be that difficult. Also it should be somewhat quicker for larger Widgets with lots of Components as you're not rebuilding its list every time.

Agent_9191
Thanks... that's helpful -- yeah, this sounds better (and not too painful). There's a crap load of javascript that drives some of the edit views (per Component) so editing the code can be an exercise in frustration.
Andrew Flanagan