In Day3 , I got around the serialization Linq to SQL, today I noticed the LinqDataContext update was not successful in CSLA. The problem is: GetOriginalEntityState couldn’t return the ‘original’ entity due to the DataContext is not serializable. Our stored procedure needs those original values.
Here comes another word around:
- Create a new public SaveEntity method in IDataContext, basically copied from the private UpdateEntity but the orginal object becomes a parameter, which should be feeded by CSLA BO.
- In CSLA BO, right after DataPortal_Fetch, do a Clone, to save original values. (needs to declare a internal Entity variable.) I still not sure is this the right place to clone, what about user do a update without read first? Where can I get the original values? The sam Clone has to be done in the update method to get ready for the next time update.
- In CSLA BO’s DataPortal_Update, call the new SaveEntity method in IDataContext.
Tested and passed.
Now Linq is on the track of CSLA and WCF. The only thing I don’t like here is, code duplication in new SaveEntity and the original UpdateEntity generated from Linq to SQL desinger. I hope Microsoft can generate UpdateEntity like this way:
private void UpdateTrainee(Trainee obj, Trainee original)
private void UpdateTrainee(Trainee obj)
Trainee original = ((Trainee)(Trainees.GetOriginalEntityState(obj)));
UpdateTrainee( obj, original);
So it can cut down a lot of code duplication.
Another question is, how come UpdateEntity doesn’t return error code or throw database exception? Curious. Our SP has whole bunch of those kind of animals.