CSLA 3.7 + VB Save method not returning new saved object.

CSLA 3.7 + VB Save method not returning new saved object.

Old forum URL: forums.lhotka.net/forums/t/7515.aspx


jamie.clayton posted on Wednesday, August 26, 2009

G'day,

I've got some VB CSLA code that was using CSLA v3.0.5 and I recently updated it to reference the 3.7 C# edition to start taking advantage of the new Codesmith CSLA templates.

When the code reaches the Public Overrides Function Save() method it correctly saves the record to the SQL Server 2005 database (and in the dataportal_Insert() methods), but at the end of the process the save method doesn't return the new object (with all the database fields (ID/Identity) fields that got saved during the process. Now this is done in the CSLA.BusinessObject.OnSave() method from what I can determine.

I'm saving a Parent/child business object. I haven't run a full debug to see what happens to the process when the code enters the CSLA C# codebase, but I can see there are a lot of differences in the code (VB/C# language differences aside).

I'm not sure where to go from here? Is anyone else experiencing this problem?

JoeFallon1 replied on Thursday, August 27, 2009

As stated many times here you are experiencing the #1 bug in user written code. Rocky recognized this issue a few versions back and implemented code to resolve it. He also warned everyone the change was coming - many times. Finally in 3.5 or so he fully implemented the change which "broke" some user's code. The issue had to do with the way the local dataportal ran differently than a remote data portal. A user could write code that worked locally but when remoting was turned on the code would fail.

Your code most likely reads like this:

myBO.Save()

That no longer works.

You need to use code like this:

myBO = myBO.Save()

The Save method returns the new copy of the BO to your UI - so you need to update your reference. The old code did not serialize a local dataportal so it "just happened to work". You can set a switch to return to the old behavior - but you must realize that your code will then never work in a remoting environment - one of the big features of using CSLA.

HTH

Joe

 

 

 

 

jamie.clayton replied on Tuesday, September 01, 2009

Joe,

Sorry about my slow reply.

You are correct, my Nunit tests were "lazy" with the save method. I've made the changes and in my Nunit code and the tests now pass. :)

I did learn that VB didn't like code in the form

With myBO
.myProperty = xyz
myBO = .Save
End with

I had to do
With myBO
.myProperty = xyz
End with
myBO = myBO.Save

I've setup a review of all my CSLA projects for .Save() methods and I'm sure it will be the Nunit code that will need changes.

In my WPF application I tried to use a code pattern in my Sub Save() method like

Dim tmpBO As BO= myBO.Clone
myBO = tmpBO.Save

I noticed in CSLA3.7 that I had to add CSLA to the list of references to get the clone method. I'm assuming that this code pattern is now out of date with the changes to the myBO.Save codebase.

JoeFallon1 replied on Wednesday, September 02, 2009

Jamie Clayton:
I'm assuming that this code pattern is now out of date with the changes to the myBO.Save codebase.

Yes - why do the clone yourself now that the framework does it for you.

Joe

 

ajj3085 replied on Friday, September 04, 2009

Not necessarly.. if you want to rebind to the object prior to the Save call (so at least the user has what they did prior to clicking save), you'll need to clone yourself because you can't get to the DP's cloned copy.

Copyright (c) Marimer LLC