Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>It encapsulates the compiler generated field, and provides you, the <code>class</code> or <code>struct</code> developer the ability to update it internally later without breaking your API by simply modifying the <code>get</code>/<code>set</code> part that you care about.</p> <p>For instance, suddenly never want to return <code>null</code>? You can do that by simply changing the empty <code>get</code> to <code>get { return storedName ?? ""; }</code>. Of course, it means you suddenly need to manually control the variable, but that's a small price to pay for the flexibility.</p> <hr> <p>The first use is an example of a <a href="http://msdn.microsoft.com/en-us/library/ms173118.aspx" rel="noreferrer">field</a> declaration. The second use is an example of an <a href="http://msdn.microsoft.com/en-us/library/bb384054.aspx" rel="noreferrer">auto-implemented property</a>.</p> <p>It is generally bad practice to provide direct access to a field. However, the .NET team noticed that a lot of getters/setters are basically just that. For example, consider the following:</p> <pre><code>// C# public string Name { get { return name; } set { name = value; } } // Without properties (or a Java implementation) public void setName(String name) { this.name = name; } public String getName() { return name; } </code></pre> <p>Either way, that's a lot verbosity to really just expose a field. However, it is regularly the case that, as a developer, you need to go back and change how a field is handled internally, but you <em>do not</em> want to break or even affect other code if you can get away with it.</p> <p>That is why using direct access to fields is bad. If you provide direct access to fields, but need to change something about using the field, then all code that uses that field must change as well. If you use a property (or even a method), then you can change the internal code and potentially not effect external code.</p> <p>Consider the following example:</p> <pre><code>public string Name { get; set; } </code></pre> <p>Later you decide that you need to raise a changing and changed event around the setter. If you exposed a field, then it's time for a potentially big rewrite. If you used properties (or a method), then you can just add the logic there. You suddenly lose the benefit of auto-implementing properties, but you gained the ability to refactor your class without breaking existing code.</p> <pre><code>private string name; public event NameChangingEventHandler NameChanging; public event NameChangedEventHandler NameChanged; public string Name { get { return name; } set { OnNameChanging(/*...*/); name = value; OnNameChanged(/*...*/); } } protected virtual void OnNameChanging(/*...*/) { } protected virtual void OnNameChanged(/*...*/) { } </code></pre> <p>All of that maintains your public API and requires no work from users of the class (the rest of your code, or external developers using of your API). Breaking changes are not always avoidable, but avoiding direct access to fields is a good step to try to ensure that it won't happen. Auto-implemented properties are a quick, and easy way to do it.</p> <p>(Unrelated: lost power while typing this and I am very happy that my browser saved most of it!)</p>
    singulars
    1. This table or related slice is empty.
    1. POWhy do we use blank get; set; accessors in C#?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USpickypg
    1. USpickypg
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POWhy do we use blank get; set; accessors in C#?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COGood answer; you'll get my +1 if you mention the difference between properties and fields.
      singulars
      1. PO
      1. USJustin Morgan
    2. COThat sorta makes sense, but if you have `string name;` and later you decide 'pants, i want to restrict the set; to not null', you can just change it to string name {get; set { .. } } surely? Other code will be doing myObject.name and won't notice the difference...
      singulars
      1. PO
      1. USNibblyPig
    3. CO@SLC: Other code will notice the difference. Under the hood, `string name;` declares a location within the object where a pointer to a string is stored. `string name {get; set;}` declares a set of procedures that can be used to ask the object for a string, or tell the object to store it (the location where this string is stored is automatically generated by the compiler). Since they're so different, the actual instructions for working with them are different - and so if you change from one to then other code will break unless you recompile it.
      singulars
      1. PO
      1. USSean U
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload