How to Store Object State/Data for Later Processing

This sounds suspiciously like you're trying to invent output caching. I definitely wouldn't agree that it's hard to do partial page caching in MVC, it's just that you would need to use partial Views with their own Controller actions to do it as opposed to having the View itself call its sub-Views, which can be slightly counter-intuitive. (So in ASP.net MVC you'd want to use Html.RenderAction as opposed to Html.RenderPartial). There's a name for this particular pattern that is currently escaping my recollection.

I would suggest that the main flaw with your design is that Views will have to know things about the architecture of the site. So they'll have to know about where to get their data from AND how to get it, they'll have to know about where to cache it, when to cache it, when not to cache it, etc.

Realistically you should be trying to separate layers away from knowledge of other layers, as the less knowledge each layer has of another the easier it is to change a layer (i.e. switch DB, add a transparent data caching layer, move a DB call across to a web service, etc.).

I would suggest that if you're going to implement such an idea, and there isn't a native output caching system in your MVC-framework-of-choice, that you add the caching layer to the Controller actions. Unless you've got some VERY heavyweight Views that need to do large amounts of recursive rendering of Models (something that's very rare) the actual HTML generation time is miniscule compared to DB calls and client network latency, so take a more pragmatic approach and cache where you need to cache, i.e. in the application layer.

If you really need custom output caching then you probably want to just slip in a caching layer above your Controller actions with either a wrapping class (if you're using a dynamic language) or a different implementation of an interface (if in a static language) that can hijack the calls to the Action and react accordingly.

As for caching that reacts to DB changes, you'd be better off with a caching layer that takes into account both loading and saving in your repository class, with each save call flushing the cache (or part of the cached set) and each load being gracefully degraded from cache to DB when needed (i.e. use the cache when the cached data is available). That way you keep the database driven behaviour close to the database.

I see that this problem is not a programming problem as much as it is a schema design problem. Where to place the properties and method may comes secondary to identifying database columns if you are mapping tables to classes in 1-1 or near 1-1 fashion.

I personally see that after the data type has been changed, you should have run a report comparing old totals and new totals and would probably want to involve management then update the database in batch and get all data consistent once and for all.

On the other issues, the correct answer will depend on answering the following questions:

1. Is your shop strict about normalization? If the answer is 'yes', do it the normalized way.

2. Do other systems update the tables involved?

3. Do you have less than 300 children per header? (300 is an approximate value of course)

4. Approximately one user would be accessing the same invoice header or detail at any time

The table below summarizes my opinion based on the different answers of the questions. Note that (-) means 'don't care'.

I personally prefer working with non-redundant data whenever possible and would place data correctness and integrity over performance if I had to and it was up-to-me, so I am biased. I made the assumption that an invoice is usually accessed only few times after its creation.

Also notice that the calculation need not be physically stored as table column, instead it could be calculated in a view and that view is used by any program wishing to access this information. Make sure your reporting software can use views before you do this.