Hi:
I'm moving my solution from CSLA 3.8 to 4.0. I've noticed that readonly classes like ProjectInfo had a friend New in previous versions but now in CSLA 4.0 those classes have a Fetch method?
Is there a paticular reason for that change?
Can I keep using the old way for the "Info" classes?
Thanks,
LMSantin
I suspect you can continue to use the old way, as long as you properly set the metastate.
If you use the data portal's FetchChild like I discuss in the Data Access ebook (and in Expert 2008 Business Objects), then the data portal will handle the metastate for you. This isn't a new feature - it was introduced in 3.6 (I think).
Sorry Rocky for my incomplete answer.
I was working in CSLA 3.6 and now I am moving to CSLA 4.0.
You're right (of course), in the "Expert 2008 Business Objects" book you treated the readonly objects (root and child) with a Fetch.
My missundertanding was that I thought the ResourceInfo object was a kind of readonlyroot or child object.
Please, tell me if my conclusion is wrong or right.
I read again Expert 2008 Business Objects and I noticed you treated the ResourceInfo object like special readonly object because in that object is not useful or needful handling the metastate.
Your words in the text:
"Each ResourceInfo object provides read-only access to a subset of data from the Resources table."
"I’m not using the field manager for this object, and I often don’t use it for simple read-only
objects. Although ReadOnlyBase supports the field manager, if your read-only object has no authorization
rules, then the field manager will provide no real value, and you can write code similar to that
shown here."
Also, in the sample code I download for that book, I saw that objects with private backing field and with friendly new method and no data access methods.
I'm not intended to use SilverLight, so, Can I defined my XInfo objects like ResourceInfo en ProjectTracker for CSLA 3.6?
Thanks again Rocky
I see. Yes, I used to sometimes create read-only objects as simple Serializable classes that didn't inherit from a CSLA base class.
In today's world with Silverlight and WP7 that doesn't work, so I no longer do that.
fwiw, at some point I would like to make core CSLA work in medium/partial trust on a web server - at which point ASP.NET and possible app server code will be subject to those same limitations. To achieve the partial trust goal we have to stop using BinaryFormatter/NDCS - which means using MobileFormatter - and that's where these serialization limitations come into play.
Thanks Rocky.
What I can understand is that in the case of InfoObjects(members of a ReadOnlyList), in order to be "technologically up-to-date" it will be better:
-Creating a class inheriting from ReadOnlyRoot
-All properties being managed backing fields.
-Loading the object with a no-database- acces Fetch Method and passing it the properies values through a object type parameter.
Is that ok?
LMSantin
That is what I do, yes.
I generally assume that all my classes might, at some point in the future, end up running in Silverlight, WP7, MonoTouch, MonoDroid, or some other environment where the Silverlight limits are in place.
You don't have to follow that recommendation, and many of the older techniques do continue to work as long as you never leave full .NET.
Copyright (c) Marimer LLC