Hi,
I have a few properties which were private, but had some rules tied to them. They end up being set by a method call, not your normal set via property.
I was suprised to encounter an error when the CommonRules.StringRequired rule was run; I was getting a NullReferenceException when the rule ran.
I traced the problem and it looks like in the Utilities class the CallByName method only gets public properties.
Would this be considered a bug, or should all Csla properties be public? I'm using 3.8.1.
Thanks
Andy
Well this is all within Csla code, so I haven't tried modifying it.
I put the rule on to ensure that the method was called pretty much. Part of the method call sets the property, then fires the rule check. I wanted the method call because it reads a file, which may take a while, so it didn't seem right to do that in response to a property changed.
I understand this might not be the best way, but its quick, and I fixed it by just making the property public, so its not a big deal, but was just wondering if there was a conscience decision to only support public properties or not.
ajj3085:
Would this be considered a bug, or should all Csla properties be public? I'm using 3.8.1.
Not a bug, no. The common rules are built with the assumption that they shouldn't break encapsulation - that they should operate on public properties.
Breaking encapsulation isn't ideal, and I didn't (don't) want to encourage doing so. I understand that it can make some things easier, but it is still dangerous.
As the author of an object, when you declare something as private you rather expect it to be private. When things break encapsulation, it violates that basic expectation. It changes the very nature of the contract between object and consumer, so now the author of the object can no longer assume the private member belongs only to the object. It now belongs to the entity that's breaking encapsulation too.
So renaming the private member should be a non-issue right? It is private after all. But now even a simple rename of a member becomes a breaking change. And not one the Visual Studio refactoring tools will help you find - because they too assume people wouldn't do something like this.
This is why I have always been so resistent to externalized DAL code. Almost by definition that code breaks encapsulation and thus increases the maintenance costs of your code. (though I think public PropertyInfo objects and the ObjectFactory base class help with this)
Ideally your properties would be public. Or you'd define an interface to expose them. In short, hopefully you'd expose the values in such a way that they are accessible without resorting to hacks like reflection.
Ok, glad to know your thoughts on this. I did end up simply making the property public, at least public read-only.
The only reason I have the property at all is because I've been favoring creating PropertyInfo[T] objects so that Csla manages the field value, in case I decide to move to Silverlight.
Since I had the PropertyInfo[T] and a rule I needed checked, i just threw it on there, and that's how I got where I was.
Thanks for the insight.
Copyright (c) Marimer LLC