CSLA .NET version 3.5 Beta 2 is now available for download from www.lhotka.net/cslanet/download.aspx.
Please read the change log prior to installing/using this release. If you are coming from version 3.0 or lower there are a few potential breaking changes. If you are coming from 3.5 Beta 1 there is one potential breaking change.
There are numerous bug fixes and feature tweaks from Beta 1 to Beta 2. These are thanks to the great feedback and help I've recieved from numerous people on the CSLA forum (http://forums.lhotka.net) - thank you all for your help!!!
I am excited to release Beta 2, because we're narrowing in on a final release of version 3.5 and any changes now will be bug fixes or stabilization. Any testing you can do on this new release is appreciated and will help ensure high quality in the final release.
Excellent news Rocky, just the news I needed today.
Now I can get rolling in earnest.
Cheers!
Ryan
Kaveh:
1- I have a rather vague idea of creating some UI/JSON extension methods for CSLA base classes via reflection for example, based on the properties each class has and on the role the user is currently in, in order to stream line the rendering process in ASP.Net MVC scenario or WCF Ajax enabled web services (for a full fledged ajax app) and I just wanted to ask Ur opinion about this. Am I far from the correct design in this? On a relatively irrelevant note ... could you please put together some ASP MVC samples leveraging CSLA?
It is relatively easy to serialize an object's properties into another format (xml, json or whatever). Deserializing data back into objects is hard. Very hard. Deserializing into a single object isn't so bad, but as soon as you have an object graph, especially if you allow circular or multiple references within the graph, it is really hard.
So I can't recommend writing your own serializer/formatter. But if you do go down that road I wish you the best of luck!
Kaveh:
2- When I bumped into the MS Enterprise Lib, I found some patterns, like validation rules for properties via attributes and the like, which are really close to the patterns you use in your CSLA but are somehow different and I was wondering that sticking with which one could be more rationale? are MS Ent Lib's patterns gonna be used in the latest CSLA or is it not that an important issue?
I have no plans to merge Enterprise Library into CSLA. I'm not sure the licenses would be compatible for one thing, and for another I don't want to take a dependency on something that not only isn't a Microsoft product, but isn't even guaranteed to be supported, maintained or enhanced going forward into the future. That's a risk I'm unwilling to accept for CSLA.
Kaveh:
A big fan of you, your business objects books and your CSLA framework from a country whose capital city wasn't even in the time zone list during the registration ! ... Since when is my home city, Tehran, omitted from the standard timezones?! Since the declaration of Iran as an axis of evil country?! :-)
You mean the timezone on this forum? If your zone isn't listed you should probably go lobby the CommunityServer people on their forum. I just use their software, I don't have any control over what timezones, languages or other features are in the software.
Rocky,
As an FYI -
I have just installed VS 2008. I copied my large web app and upgraded it to use VS 2008 using CSLA 2.x still. (I had to overcome a side issue with an older 3rd party .dll.) But now that I have everything converted I ran the app and it worked as expected.
So I compiled the Beta and tossed it in to my app and re-compiled - I got a lot of compile errors.
5 of them are due to the spelling change of AddDependantProperty to AddDependentProperty.
30 of them are for a Namespace collision between System.Reflection and CSLA.Reflection. It turns out I have a lot of places in my code where I use "Reflection.PropertyInfo". I think the fix is simple enough - just remove the "Reflection." from the code.
I had to remove the reference and add it back and then I got a clean compile!
I thought that I would have had some issues since I missed 3.0.x. I will have to review things closer in the future but for now I am happy to get it running.
Joe
You are not using the CanReadProperty/CanWriteProperty/PropertyHasChanged overloads that auto-determine the property name? That's good, because in my code that's the hardest thing to overcome.
I rarely use reflection in my business object code, so the Reflection namespace collision hasn't been an issue.
I have run into the AddDependentProperty change, but that's fixed with ctl-shift-H (replace in all files).
But I habitually used the now-obsolete overloads of the CanXYZProperty methods, and so I've had to rework all my property declarations - and that ends up being a lot of work...
The easiest solution is to use snippets to just recreate the properties. And to use the private backing field option rather than the managed field option - because that avoids having to rework the data access code that interacts directly with the fields.
Though for new code I am using the managed field option, because that's even less code in the end.
You are not using the CanReadProperty/CanWriteProperty/PropertyHasChanged overloads that auto-determine the property name? That's good, because in my code that's the hardest thing to overcome.
But I habitually used the now-obsolete overloads of the CanXYZProperty methods, and so I've had to rework all my property declarations - and that ends up being a lot of work...
I avoided that can of worms from Day 1.
I never liked it and am glad you deprecated it.
Since I use Codesmith to Generate Properties, the extra work and use of string literals was never really an issue for me.
I could not play with the Beta before because I could not install VS 2008 until we fixed the 3rd party .dll problem (which we didn't know was the source of our trouble until.... you get the idea.)
I would like to take a look at the new Property declarations. I am not sure if we will just stick with the original style or not. Again since they are code generated they are not much of an issue. We will have to weigh the benefits of making such a move.
Joe
Copyright (c) Marimer LLC