CSLA 4 with Silverlight conversion issues

CSLA 4 with Silverlight conversion issues

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

digigeek posted on Monday, August 16, 2010

I'm trying to convert some VB business objects, which were written for CSLA 2 and am running into various deprecation problems. Most of them are well-covered on your other web site, but this is one is stumping me.

These guys were doing:

#Region " Data Portal "
Private Overloads Sub Fetch(ByVal dr As Csla.Data.SafeDataReader)
    _DbId = dr.GetInt32("UndTemplateId")
    dr.GetBytes("LastUpdate", 0, _LastUpdate, 0, 8)
    _ConditionId = dr.GetInt32("UndConditionId")
    _ConditionIdAsString = _ConditionId.ToString
    _Section = dr.GetString("Section")
    ' I already fixed this deprecated class
End Sub

Of course, Csla.Data.SafeReader does not exist any longer. What's the proper course of action?



James Cates

Jav replied on Monday, August 16, 2010


1.  Going from Csla 2.x to 4.0 is a huge jump.
2.  SafeDataReader does exist in Csla 4.0  I am assuming that the phrase "Csla.Data.SafeReader" in your message is a typo. Your Method argument is correct.  Also dr.GetInt32("UndTemplateId") and other lines are correct.
3.  I think SafeDataReader is the least of your problems.


digigeek replied on Tuesday, August 17, 2010

That's really disheartening. Surely, a lot of people will want to move to the latest version of CSLA. That sort of thing should never be massively painful to accomplish. I see no Csla.Data.SafeDataReader in my v 4.0 Silverlight DLL. None at all.

tmg4340 replied on Tuesday, August 17, 2010

The SafeDataReader doesn't exist in the Silverlight CSLA assembly because Silverlight has no concept of ADO.NET.  SafeDataReader still exists in the full-.NET CSLA assembly, which is what you would use on the server to retrieve your Silverlight data.  You might want to take a look at the 3.8 video series that Rocky has created - CSLA in Silverlight works much differently than you're probably used to.

It's hard to make upgrading two major versions of any product not painful, massively or otherwise.  Rocky has done a lot of work to make sure there's a good level of backwards compatability, but it's not 100%.  And if you weren't using Silverlight, you could probably keep a fair amount of your existing codebase (though there are now much better ways of doing a lot of things.)  However, since you're going to Silverlight, the way you create BO's is quite different, and unfortunately much of your existing codebase is simply going to have to be re-worked to comply with that.  This is because of Silverlight constraints on what's possible in the SL runtime.  Again, checking out the video series, blog posts, forum posts, etc. - as well as the 2008 book - should give you the information you need.


- Scott

Copyright (c) Marimer LLC