Update only 1 field of a big Business Object inside a transaction (Best approach) ?

views:

answers:

+1 Q:

Update only 1 field of a big Business Object inside a transaction (Best approach) ?

Hello fellows, Good day.

I am in a situation where I have to perform a transaction master detail record (Drop prev details, insert new details, Update Master status)

Master Business Object has 20 fields
Details Business Object has 4 fields only

Now I have to update only 1 field in master table and 4 fields in details table for insert.

If I initialize a new master object, 19 fields are being wasted for a simple update. What do I do to efficiently handle this situation ?

Can I make a new object and inherit only one field from my master business object ? Please give me a little working example if you advise me a DTO or something with inheritance. Thanks.

+1 A:

I guess you mean exposing those 4 fields, instead of inheriting them since you cannot really inherit fields, only a class.

You could make a smaller, simpler 'update object', but I would only do so if this smaller object also exists logically in your model. Ideally, you really don't want to create special objects for updating only parts of your business objects. Instead, it's the task of your persistence layer to be smart enough to know which fields have changed and act accordingly (ie only update those fields).

So in summary:

Make an update object only if its also a logical part of your Domain Model
Trust in your persistence layer to see what has changed.

Sam 2010-08-19 07:21:31

Thanks for the reply Sam. I can make a simpler business object with 4 fields but it creates redundancy(same fields in both objects).What do you mean by 'exist logically in your model' ? In master child, I have to update 'last updated field' in master whenever childs are updated.

Popo 2010-08-19 07:29:12

I mean that in an ideal design world, your objects will be modelled after your 'real-world' business concepts, not your technical requirements. This is of course not always 100% possible (some persistence layers will require you - for example - to decorate your business objects with some attributes to indicate how they should be saved to the database). Even so, I'm not a big fan to use 'reduced' objects, the exception possibly being if you have to do a lot of serialisation (for example a wcf service) and serializing all those empty fields would have an impact on your performance.

Sam 2010-08-19 07:48:34

Hmm, thanks Sam that does make sense. I never ever thought about serializing but in my case it won't be required. Is it advisable to break my large business object into small objects and return their combination when required? That would make my job easier.

Popo 2010-08-19 07:52:31

You could do that, but if you have to consistenly split up your business objects into smaller (logical) ones, maybe you should consider that your business object has been designed too broadly to be useable? In that case, splitting it up into smaller objects would make sense indeed.

Sam 2010-08-19 07:59:53

thank you Sam, I am splitting the business object into 2 objects for the time being. I will wait for more suggestion for some time, if not I will mark yours as answer.

Popo 2010-08-19 08:13:31

Create DTO with those 4 fields. UI will send this DTO to business layer which will use new values to modify business object. Than you persist that modified business object.

Ladislav Mrnka 2010-08-19 07:37:01

Sorry my bad, I am new to this persistent layer altogether. Won't the DTO be taken to a separate DB layer for updation ? Also what do you mean by modifying the business object ? If I would take this inside a DTO I might not mess with the Master Business object because that would mean initializing all the fields.

Popo 2010-08-19 07:44:25

ansaurus

tags:

views:

answers:

Update only 1 field of a big Business Object inside a transaction (Best approach) ?

related questions