Home/ Questions/Q 703813
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T03:52:21+00:00

I have a Linq-To-Sql based repository class which I have been successfully using. I

  • 0

I have a Linq-To-Sql based repository class which I have been successfully using. I am adding some functionality to the solution, which will provide WCF based access to the database.

I have not exposed the generated Linq classes as DataContracts, I’ve instead created my own “ViewModel” as a POCO for each entity I am going to be returning.

My question is, in order to do updates and take advantage of some of the Linq-To-Sql features like cyclic references from within my Service, do I need to add a Rowversion/Timestamp field to each table in by database so I can use code like dc.Table.Attach(myDisconnectedObject)? The alternitive, seems ugly:

var updateModel = dc.Table.SingleOrDefault(t => t.ID == myDisconnectedObject.ID);
updateModel.PropertyA = myDisconnectedObject.PropertyA;
updateModel.PropertyB = myDisconnectedObject.PropertyB;
updateModel.PropertyC = myDisconnectedObject.PropertyC;
// and so on and so forth
dc.SubmitChanges();
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I guess a RowVersion/TimeStamp column on each table might be the best and least intrusive option – just basically check for that one value, and you’re sure whether or not your data might have been modified in the mean time. All other columns can be set to Update Check=Never. This will take care of handling the possible concurrency issues when updating your database from “returning” objects.

    However, the other thing you should definitely check out is AutoMapper – it’s a great little component to ease those left-right-assignment orgies you have to go through when using ViewModels / Data Transfer Objects by making this mapping between two object types a snap. It’s well used, well tested, used by many and very stable – a winner!

    • 0