private PropertyInfoDataCache __currentcache;
...
protected PropertyInfoDataCache PropertyCache
{
get
{
if (null == this.__currentcache)
{
this.__currentcache = PropertyInfoDataCache.RegisterPropertyInfoCache(this);
}
}
}
imho it comes down to consistency. Previously when you had a property, you had to implement about half a dozen lines of code to make sure that it would operate correctly. Thus meaning that as new functionality comes on board (whether from CSLA or logic that you want to implement specifically) you would have to go through and make all these changes to every single property and the chances of mission one somewhere is fairly high. With the new method, when you set a property or get a property it is going through a central conduit meaning that the results are always going to be consistent. It's kind of like the same reason why the DataPortal exists. Its might better to have one central point that many different ones which you have to manage and maintain. And with this you do pay a small pref cost but you do with the dataportal as well, yet the dataportal is used as it is good design practice. And if performance is an issue (even though i think the current implementation is fairly good in this regard) you can still go back to using your own private variables and put the plumbing into each property and because the businessbase is mostly lazy load you wont be any worse off than you where before. But if you do go to the new system, your constancy and reliability (when it comes to the application of auth and val rules) will be a lot higher.
I might have it wrong but i think that is the main jist of it and as a side note i think rocky got the core idea for implementation from DependencyProperty (although i may be wrong there).
Hope that helps
Anthony
I put a summary of the syntax here
http://www.lhotka.net/Article.aspx?area=4&id=219295b4-7cb6-4ced-a0bf-8f4b56f72b57
The use of RegisterProperty() is to enhance performance, as compared to just storing PropertyInfo<T> objects as I was doing a couple weeks ago.
By using RegisterProperty(), it is possible to assemble a list of all the registered properties. Then I can put them in order using an algorithm that results in the same order every time (like on a client and a server). Then I have fixed positioning of each property, and can give each property an Index value (0 to x).
Then the field values themselves can be stored in an array of IFieldData. Each field can be retrieved directly be index. The index comes from the PropertyInfo which is supplied to the top-level method (GetProperty, SetProperty, etc). So getting to the right IFieldData is an array lookup rather than a Dictionary lookup - MUCH faster.
The broader reason for this whole change is a combination of consistency and less code. Using this new technique (either with private fields or managed fields) results in much more consistent code that in the past - making it easier to use snippets or code-gen to create your code. And there's simply less code - about 35% less than the syntax used in my previous books for example. That adds up to a big code savings in many objects!
Additionally there's the fact that the new syntax enables CSLA to manage child objects for you. So you don't have to write all the plumbing code to deal with IsDirty/IsValid, child events, deserialization issues, etc. Lots of the complexity of using CSLA just disappeared right there!
And it enables the new child data portal features, which further reduces code/complexity when writing the data access code for child objects.
I realized this after I found the seven-page discussion about this feature. Is it permissable to move the implementation out of BaseBusiness in my copy into a separate PropertyInfoCache? In the BaseBusiness I would replace the methods with:
private PropertyInfoDataCache __currentcache;
...
protected PropertyInfoDataCache PropertyCache
{
get
{
if (null == this.__currentcache)
{
this.__currentcache = PropertyInfoDataCache.RegisterPropertyInfoCache(this);
}
}
}
My only reason is keeping the various implementations within BaseBusiness modular. Has anyone any opinions about the performance considerations of this? The really motivated could turn the property cache into a provider.
-- Nick
Please be aware that Beta 1 is not the final product – my focus
thus far has been on making it work, not on making the internal implementation
elegant :)
That code has already changed, if you look at svn, due to the
earlier feedback regarding inheritance. And it will continue to change over the
next few weeks as I do further cleanup/stability/performance work.
Some parts of the code can’t be moved out of BB though,
because some parts of the code interact with other subsystems like
validation/authorization/data binding and BB is the only location where all
those subsystems come together.
But the code you reference specifically is already gone, and
changed radically.
Rocky
From: Gravity
[mailto:cslanet@lhotka.net]
Sent: Thursday, January 31, 2008 1:17 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] CSLA .NET 3.5 property declaration syntax
I realized
this after I found the seven-page discussion about this feature. Is it
permissable to move the implementation out of BaseBusiness in my copy into a
separate PropertyInfoCache? In the BaseBusiness I would replace the methods
with:
private PropertyInfoDataCache __currentcache;
...
protected PropertyInfoDataCache PropertyCache
{
get
{
if (null == this.__currentcache)
{
this.__currentcache = PropertyInfoDataCache.RegisterPropertyInfoCache(this);
}
}
}
My only
reason is keeping the various implementations within BaseBusiness modular. Has
anyone any opinions about the performance considerations of this? The really
motivated could turn the property cache into a provider.
-- Nick
Just a very small note that the comparisons in the article are ever so subtly different.
In property accessors / setters of 3.5, to be consistent with the other examples, one still needs to include a throwOnNoAccess flag to get the same behavior as the pre-3.5 property notation.
private static PropertyInfo<string> NameProperty =
RegisterProperty<string>(typeof(ObjectType), new PropertyInfo<string>("Name"));
public string Name
{
get { return GetProperty<string>(NameProperty, true); }
set { SetProperty<string>(NameProperty, value, true); }
}
It's a minor thing but I just wanted to mention it.
Ahh, good point!!
Though as Joe has so correctly pointed out, the getter should
avoid throwing an exception, because even with the CSLA helper controls for
Windows and WPF an authorization exception is problematic. GetProperty()
defaults to returning a dummy value rather than throwing an exception –
and if you then use one of the CSLA helper controls the user never even sees
the dummy value – but at least there’s no exception to cause issues
:)
SetProperty() defaults to throwing a security exception and so
does act like the pre-3.5 approach.
Rocky
From: skagen00
[mailto:cslanet@lhotka.net]
Sent: Thursday, January 31, 2008 3:50 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] CSLA .NET 3.5 property declaration syntax
Just a very small note that the comparisons in the article are ever so
subtly different.
In property accessors / setters of 3.5, to be consistent with the other
examples, one still needs to include a throwOnNoAccess flag to get the same
behavior as the pre-3.5 property notation.
private static PropertyInfo<string> NameProperty =
RegisterProperty<string>(typeof(ObjectType), new
PropertyInfo<string>("Name"));
public string Name
{
get { return GetProperty<string>(NameProperty, true); }
set { SetProperty<string>(NameProperty, value, true); }
}
It's a minor thing but I just wanted to mention it.
Copyright (c) Marimer LLC