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
BusinessRules.CheckRules()
'ValidationRules.CheckRules()
MarkOld()
End Sub
Of course, Csla.Data.SafeReader does not exist any longer. What's the proper course of action?
Thanks,
James Cates
James
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.
Jav
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.
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.
HTH
- Scott
Copyright (c) Marimer LLC