Why are properties on classes in ASP.NET using C# generally public and properties using C# for desktop apps private?

I have searched high and low (and very possibly could have missed it), but in my years of programming, I have always come across one practice that seemed to be the standard in OOP, which is to use private properties in an object with public methods to manipulate the data.

However, the more I de开发者_C百科lve into ASP.NET (specifically with MVC), the more public properties I see inside of classes (specifically models) such as the ones shown at Scottgu's blog discussing the Entity Framework.

Does it have something to do with the way that LINQ populates a class?

Thanks in advance, and the answer may be out there, but I have been looking for a long time, and can't figure out why ASP.NET uses public and even the desktop C# apps use private.

---

You are confusing fields with properties. The concept of a property in .NET languages is basically an encapsulation of the get and set functions that you're describing.

For instance:

private int foo;

public int FooProperty
{
    get { return foo; }
    set { foo = value; ]
}

This is analagous to what you'd see otherwise like this:

private int foo;

public int getFoo()
{
    return foo;
}

public int setFoo(int value)
{
    foo = value;
}

It basically provides syntax that's similar to that of an ordinary field while providing the developer with control over the actual get and set behavior.

What may be further confusing you is that C# has a shorthand for automatic implementation of simple properties (like the one above). Doing this:

public int Foo { get; set; }

Is actually just a shorthand for this:

private int _foo;

public int Foo
{
    get { return foo; }
    set { foo = value; }
}

This allows you to use properties everywhere in your public-facing API without sacrificing the convenience of fields. This means that you can

1. Be consistent (all public members are exposed through properties, instead of a mix of properties and fields
2. Be flexible, so you can change the code behind the property to a full property at a later date (if the need arises) without changing the public-facing API and having to recompile any assemblies that referenced your type.

---

I think what you might be seeing is the Auto-Implement Property feature. This is a shortcut to expose data members as public so that you don't need to explicitly create a private data members. C# will creates a private data member for you.

Eg:

public string MyProperty { get; set; }

Is doing the same as:

public string _MyProperty; 
public string MyProperty
{
    get { return _MyProperty; }
    set { _MyProperty = value; } 
}

You could make your data members public and not use the shortcut but if you decided to change the implementation of the data member to have some logic then you would need to break the interface.

---

Be careful not to confuse Properties with Member variables. The standard in OOP was to have private "properties" when there was no concept of a property, only a member variable, then to wrap that member variable in a public method to get and set it's value. It's generally a bad idea to have a public member variable, but public properties are good practice because just like methods, they encapsulate your member variable.

---

It's also to do with how ASP.Net (and possibly also WPF, by extension? I don't know WPF but one could make a reasonable assumption) decides using reflection what you mean when you pass a string to it's databinding functions.

Given the following:

public class ImaginaryModel
{
   public string Naomi { get; set; }
   public string GetHeidi()
   {
      // do something here
   }
   public string Elle;
}

This databinding expression will work:

Eval("Naomi")

... whereas these will not:

Eval("GetHeidi")
Eval("Elle")

... because the implementation of databinding evaluation appears to be written against Type.GetProperties(). At least, this is my experience and understanding. The convention probably grew out of this.

---

Public Properties are the way the .NET community has elected to deal with this.

Note the difference here:

public int Property { get; set; } // C# auto-prop

public int Property; // C# "field"

The former is the standard way, and is generally accepted. A backing field can be added when necessary. The latter is typically avoided, since it doesn't have the get/set.

---

It's possibly a relic due to the nature of Asp.net WebForms - Properties on code-behind had to be protected at minimum, as the asp.net compiler generates wrapper classes for pages and user controls. The generated classes cannot access private properties, so protected or public is generally the way to go.

Since I'm not an MVC expert, I can't say for certain whether this still occurs in MVC - but I do know that in WinForms, the codebehind is just a partial class and there is no generation of a wrapper object, any private property is fully accessible by textboxes and the like.

Alternately, people could just be using public properties so they can more easily create proxy classes in unit testing environments (which is the main reason I would use them on a model).