Here's a question that I've wondered about often......whenever I want set a property I often first check that its necessary:
if{_field <> value){ _field = value;} sort of thing.
I wonder why in relatively expensive properties/methods CSLA doesn't to something similar. A good example is the MarkClean() method:
protected void MarkClean()
{
_isDirty = false;
OnUnknownPropertyChanged();
}
if the _isDirty flag is already false then it is a pretty expensive to go down the whole PropertyChanged road - i.e. databound grids/controls/parent collections/parents of parents/etc.
Now, it may be argued that MarkClean() should never be called on a clean object but this is just an example (and, in fact, in some peculiar circumstances I have that issue).
This is just a wondering more so than a problem.
Premature optimization is an anti-pattern.
If someone comes along and shows that this implementation is causing a measurable performance issue that causes real pain, then I'd add it to the wish list.
And that happens from time to time - when I wrote version 2.0 there were some issues around business/validation/authorization rules that led to the changes in 2.1 - very clear performance problems that needed solving.
Other things, like the possibility someone might call MarkClean() on a clean object outside the data portal (because remember that the data portal is operating on a clone of the object and the data portal does do an IsDirty check), simply haven't been called out as an issue.
Fair comment Rocky. But while on that note the fact that you mark many methods/properties as private (as opposed to virtual protected) have been a diffuclty for me (I have been using your excellent framework for the basis of my work for many years now and, in fact, in recent releases you have added many of the features I had added myself in one way or another).
Personally, I have spent many a day and night fighting with event propagation via databinding in any number of UI controls over the years. Mostly this is ok but in some cases too much(for my liking) UI code has to be written - i'd prefer to fetch/bind/format(or maybe format before bind)/edit/save without having to hook to this, that and the other event to deal with stuff firing. That's very general comment and not so useful I know. But, my feeling is that firing events only when necessary in complex scenarios where performance really does matter is the way to go.
But like I say my post was a wondering more than a problem. Thanks for taking the time to reply.
I just responded yesterday, in a different thread, to the question about why all members aren't protected virtual. Maybe that was your question?
Maybe I'm wasting forum space but I didn't really have a question about the private xxx stuff. I just mentioned it on the back of your comment that I found interesting:
Premature optimization is an anti-pattern.
Some strange patterns are formed when constraints dictate - I wondered if the privating of things (like MarkOld()) as a starting point could be classed in the same thinking. I'm a big believer in patterns but know all too well that there are good ones and bad ones. And that even the good ones aren't good all of the time.
One core concept that makes OO powerful is encpasulation. Encapsulation implies that a class or object is a 'black box' that exposes an interface for consumers to use.
Everything that is non-private becomes part of that interface - whether protected or public.
Everything that is non-private must be carefully designed to accomodate as many usage scenarios as the designer and developer can imagine - and even then someone will figure out some unsupported scenario, that's a virtual guarantee.
Take Utilities.CallByName() for example. This was internal for a long time, and life was good. I made it public a few versions ago, because it is useful for creating generic validation rules. Almost immediately I started getting feedback that the method doesn't work in this or that scenario.
Of course not. It was designed to meet the specific needs of CSLA itself, and I never really intended on writing a comprehensive reflection helper. Nor do I want to get into the business of writing a comprehensive reflection helper.
So to some degree I've regretted making that (and several other) methods public - because doing so increases my support burden in areas where I really have no interest. Internally, CSLA has all sorts of cool stuff (like CoerceValue(), dynamic method invocation, etc). Every one of those things could be a framework by itself!!
Do I want to accept responsibility for creating a comprehensive value coercion framework? Not at all! Have I essentially done so by making that method public? Absolutely.
So now, in addition to maintaining a framework that helps build object-oriented business layers in a distributed n-tier environment, I am also maintaining mini-frameworks that do
Some of these were private and I made them public - accepting the cost. Others were public to start with, because I personally can't envision building an app without them.
I'm not complaining - or at least that's not my intent. What I am doing is trying to convey why it is no small thing to make a member protected or public.
Copyright (c) Marimer LLC