-
Yes, that would work around the serialization problem. But you keep the memory overhead anyway. You also end up processing the rules twice -on client and server-, thus doubling the cpu overhead. The point of this it to keep the server light and fast. If those properties are calculated and are never read, they will never incur any overhead. With that
-
Here's a little demo app I just wrote. It only shows the size of the object graph after serialization, with and without calculated properties. It does not test: -Serialization times -Deserialization times -Dataportal fetch times All of these will be slower without calculated properties. In the first two cases because there is more data to serialize
-
Hi Jonny, Yes, I realize that you're supposed to use PropertyInfoFactory, as I said, this was done just for testing purposes. The extended class is a proof of concept, this functionality could be implemented directly in the current propertyinfo object without needing the extra extendedpropertyinfo object. It doesn't apply only to private fields
-
I created the attached class as a proof of concept. It's use is more specific for private fields but could be used for custom properties (or calculated properties as well). For my tests I just edited one of the overloads for RegisterProperty like so: protected static PropertyInfo<P> RegisterProperty<P>(Expression<Func<T, P>>
-
Hey everyone, I found an issue in the latest version. BusinessBase has this code: protected P GetProperty<P>(PropertyInfo<P> propertyInfo, P field) { return GetProperty<P>( propertyInfo.Name , field, propertyInfo.DefaultValue, Security.NoAccessBehavior.SuppressException); } Then the string version of GetProperty that this is calling
-
Well, the calculated property could definitely have its own security constraints. Imagine you have a class that has a base value, let's call it weight, 3 different price categories, one for retailers, one for class "a" customers and one for regular customers, one general cost per weight multiplier (this is an extremely over simplified
-
We will always agree on wanting the code to be simple and elegant. But the fact remains that this will add overhead and memory consumption. It's not a big problem in a single root object, but in large collections calculated properties are the way to go. Creating storage space for a calculated value will also create redundant data and increases the
-
Hi Jonny and Rocky, thanks for your replies. I see how in theory option A is great, but in practice it's impractical and it implies performance hits across all tiers. I have scenarios with 10 or more calculated properties, most of them editable and affecting other properties values, some of them are strings that are returned based on a resource
-
There is a problem when implementing a custom property, that doesn't really have it's own data, but instead consumes other properties for managing it's state. Example: 2 standard managed properties, StartValue, EndValue. 1 "custom" property that feeds on these two: DifferenceValue Public Shared ReadOnly DifferenceValueProperty
-
Does that mean that in the future the PropertyInfo objects will be exposed to consumers of the business object? Is there already an api for listing out the property info objects for a BO that I'm not aware of? Or do we need to use reflection to get the property info objects associated to a property name? To be honest, I'm not so sure I understand