Why we are using managed property?

Why we are using managed property?

Old forum URL: forums.lhotka.net/forums/t/5435.aspx


PIDC posted on Friday, September 19, 2008

Hi,

I became a CSLA.NET user one year ago. I must say i'm very happy with the framwork (thanks Rocky). I has built and and currently maintaining my business software (finance+inventory+fixed assets) with purely CSLA.NET 2.1.4 behind.

I'm considering to switch my solution to CSLA.NET 3.5. However there are some new concepts in CSLA.NET 3.5, one of them is managed property. I was digging around with managed property / dependent property concept in WWF and WPF, somehow i see the purpose of using them to simplifying Presentation Layer or property escalation in WWF. However i still confuse about the benefit we got, using managed property in CSLA. I don't care about the code files are shorter or not , because I use CODE-GEN intensively.

So, please share your idea about the managed field in CSLA. I see that they are complicated and reduce the readability of the code.

Currently, I just change the DAL in the my code-gen, so i can still generate CSLA 2.1.4 classes with LINQ for SQL in the way that CSLA 3.5 does. LINQ for Object works fine with CSLA 2.1.4 Business List Base.

Thanks for your idea.

PIDC

nermin replied on Friday, September 19, 2008

Firstly - Code reduction, as you can see in Rocky's post bellow:
http://www.lhotka.net/weblog/CSLANET35PropertyCodeReduction.aspx

That also means reducing number of bugs, as you do not have to remember
attaching all those Authentication/Validation methods on your property
get/set.

And lastly, Managed property's are used heavily for serializing values
from Silverlight to .Net and back. It is lot simpler to use those than
serializing field backed properties.

Nermin

-----Original Message-----
From: PIDC [mailto:cslanet@lhotka.net]
Sent: Friday, September 19, 2008 10:05 AM
To: Nermin Dibek
Subject: [CSLA .NET] Why we are using managed property?

Hi,

I became a CSLA.NET user one year ago. I must say i'm very happy with
the framwork (thanks Rocky). I has built and and currently maintaining
my business software (finance+inventory+fixed assets) with purely
CSLA.NET 2.1.4 behind.

I'm considering to switch my solution to CSLA.NET 3.5. However there are
some new concept in CSLA.NET 3.5, one of them is managed property. I
have digged around with managed property in WWF and WPF. However i still
confuse about the benefit we got, using managed property in CSLA. I
don't care about the code files are shorter or not , because I use
CODE-GEN intensively.

So, please share your idea about the managed field in CSLA. I see that
they are complicated and reduce the readability of the code.

Currently, I just change the DAL in the my code-gen, so i can still
generate CSLA 2.1.4 classes with LINQ for SQL in the way that CSLA 3.5
does. LINQ for Object works fine with CSLA 2.1.4 Business List Base.

Thanks for your idea.

PIDC

PIDC replied on Friday, September 19, 2008

Hi Nermin,

As in my first post, reducing the code is not important in my case because i use code-gen a lot.

Also, i don't have any problem with Validation/Authentication, because most of my validation rule are described in a xml file. I make CSLA Validation automatic utilize them without coder's intervention.

About serialization, i think that i will never write code to implement serialization. I'm focusing on my business domain and rely on CSLA to help with technical things.

So, is there any problem if i use CSLA 3.5 + normal "unmanaged" property together ? Does CSLA 3.5 serialize them as fine as CSLA 2.1.4 does?

Thanks.
PIDC



tetranz replied on Friday, September 19, 2008

I guess this is a minor thing but another code reduction advantage I like is that the properties get sensible defaults, most notably strings are empty rather than null. I prefer empty (better for databinding) and I used to set these in my DP_Create or have field initializers but that's unnecessary now.

I'm not using code generation for now. I find that snippets make the managed properties quick and easy to use.

PIDC replied on Friday, September 19, 2008

Hi Tetranz,

unmanaged field support default value very well.

for example:

Dim _strField as string = String.Empty
Dim _sdField as SmartDate = new SmartDate()
....

With the managed field you will need to do the same thing while register the property





JoeFallon1 replied on Friday, September 19, 2008

I plan to use the "old style" properties for exactly the same reasons that you cite.

I find them more readable and I code gen them so it doesn't matter.

I plan to look in to Silverlight and will definitely need to make use of Managed Properties for that scenario. But I have so much on muy plate right now that I plan to keep going with what works.

Joe

 

PIDC replied on Friday, September 19, 2008

It seems that, the main purpose of using managed property is make the serialization easier. With "old style" field/property CSLA uses reflection to get the list of fields for serialization. Now, in CSLA 3.5 reflection is not required, CSLA just need to serialize the collection of managed fields. (Please correct if i'm wrong).

I still have a question : Can we use CSLA 3.5 with "old-style" field/property without any problem ?

If you know the answer, please advice.

Thanks,

PIDC

RockfordLhotka replied on Friday, September 19, 2008

There are two things going on here.

First, there's the RegisterProperty() and PropertyInfo<T> concepts. These exist primarily to eliminate the use of string literals throughout class files. They can be used with or without managed backing fields, and I recommend using them.

I don't know for certain that you can do without them in version 3.5+. My testing has focused on using an IPropertyInfo object instead of a string literal in every case.

However, there are older unit tests that still function - using the string literal appraoch - so most functionality should be accessible. Certainly all 3.0 functionality continues to work as it did - backward compatibilty is preserved.

Second, there's the private backing field vs managed backing field question. Managed backing fields require PropertyInfo<T>, private backing fields work with or without (as per my first point).

Managed backing fields do two things: they reduce code and they serialize automatically to Silverlight - at the cost of lower performance.

Private backing fields do one thing: provide better performance - at the cost of a little more code, and a lot more code if you want to serialize to Silverlight.

The Silverlight serialization thing is just a Silverlight issue today. However, looking into the future it is clear that the same techniques used in CSLA .NET for Silverlight could be used to create CSLA .NET for other restricted security environments. In other words, you could envision a version of CSLA that worked on a web server and didn't require full trust. That'd be nice for public hosting scenarios, etc.

You can also envision a variant (probably a small variant) of CSLA .NET for Silverlight that worked on the Compact Framework. The solutions for the Silverlight trust and serialization issues would help address similar issues in CF.

The thing is, private backing fields work with Silverlight too - you just have to write (or generate) a couple methods to do the serialization/deserialization of all your private fields. If you are using code-gen you may not care. But if you are coding by hand, you really care because those methods are likely to be long, boring and hard to debug.

PIDC replied on Friday, September 26, 2008

Thank You for the answer, It helps me a lot to choose the upgrading path for my product. I'm waiting for your next book (CSLA 3.5).

ajj3085 replied on Friday, September 19, 2008

Well, if you don't see a value you don't need to use them, unless you're going to use Csla.net for Silverlight.

But if you're doing a regular application, just keep going on as you were.

I disagree though about reducing readability; there's so much less code (code that was never really that interesting anyway) I believe they increase readability and reduce bugs... because there's less I need to change to fix things.

PIDC replied on Friday, September 19, 2008

hi ajj3085,

May be i will change my opinion about the readability when Rocky release his next book or when i move on to study them.

I think it's better for me to keep my current application as is and develop a seperate silverlight solution for Reporting / Business Intelligent Tools.

Thanks for your comment.

PIDC

Copyright (c) Marimer LLC