I'm going to build my MVC Web Application and I created my data models.
I found online many ways to compile a data model code. This is easiest one, using only public properties:
public class Person
{
public int Id { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
}
But I also found a version using a private variable and a public properies, like this:
public class Person
{
private int id;
private string firstName;
private string lastName;
public int Id { get { return id; } set { id = value; } }
public string FirstName { get { return firstName; } set { firstName = value; } }
public string LastName { get { return lastName; } set { lastName = value; } }
}
What is the difference between these two data models?
When is more advisable using the first one or the second one?
This is the same like asking: what is a difference bwteen auto properties and normal properties.
Auto properties:
easy creation (less to type)
internal field is generated for you automatically by compiler
Not possible to debug (set a break point inside the property)
Normal properties
Sligtly more code to type
Easy to debug
More code can be injected inside get and set
If first example compiler will create private field for every automatic property itself, but they behave exactly the same. More info on MSDN
I would suggest second approach as you have more control how property works, but there is nothing wrong in using first one.
The fiest block you have are auto-properties, and under the hood the c# will be compiled similar to the second block, so in this case there is no difference. Take a look at these posts here:
C# 3.0 auto-properties - useful or not?
What are Automatic Properties in C# and what is their purpose?
Any reason to use auto-implemented properties over manual implemented properties?
If you were implementing the INotifyPropertyChanged interface, then you would need to use the traditional way as you would be interacting with the property in the setter, see example...
http://msdn.microsoft.com/en-us/library/ms743695.aspx
I am learning ASP.NET MVC and I can read English documents, but I don't really understand what is happening in this code:
public class Genre
{
public string Name { get; set; }
}
What does this mean: { get; set; }?
It's a so-called auto property, and is essentially a shorthand for the following (similar code will be generated by the compiler):
private string name;
public string Name
{
get
{
return this.name;
}
set
{
this.name = value;
}
}
So as I understand it { get; set; } is an "auto property" which just like #Klaus and #Brandon said is shorthand for writing a property with a "backing field." So in this case:
public class Genre
{
private string name; // This is the backing field
public string Name // This is your property
{
get => name;
set => name = value;
}
}
However if you're like me - about an hour or so ago - you don't really understand what properties and accessors are, and you don't have the best understanding of some basic terminologies either. MSDN is a great tool for learning stuff like this but it's not always easy to understand for beginners. So I'm gonna try to explain this more in-depth here.
get and set are accessors, meaning they're able to access data and info in private fields (usually from a backing field) and usually do so from public properties (as you can see in the above example).
There's no denying that the above statement is pretty confusing, so let's go into some examples. Let's say this code is referring to genres of music. So within the class Genre, we're going to want different genres of music. Let's say we want to have 3 genres: Hip Hop, Rock, and Country. To do this we would use the name of the Class to create new instances of that class.
Genre g1 = new Genre(); //Here we're creating a new instance of the class "Genre"
//called g1. We'll create as many as we need (3)
Genre g2 = new Genre();
Genre g3 = new Genre();
//Note the () following new Genre. I believe that's essential since we're creating a
//new instance of a class (Like I said, I'm a beginner so I can't tell you exactly why
//it's there but I do know it's essential)
Now that we've created the instances of the Genre class we can set the genre names using the 'Name' property that was set way up above.
public string Name //Again, this is the 'Name' property
{ get; set; } //And this is the shorthand version the process we're doing right now
We can set the name of 'g1' to Hip Hop by writing the following
g1.Name = "Hip Hop";
What's happening here is sort of complex. Like I said before, get and set access information from private fields that you otherwise wouldn't be able to access. get can only read information from that private field and return it. set can only write information in that private field. But by having a property with both get and set we're able do both of those functions. And by writing g1.Name = "Hip Hop"; we are specifically using the set function from our Name property
set uses an implicit variable called value. Basically what this means is any time you see "value" within set, it's referring to a variable; the "value" variable. When we write g1.Name = we're using the = to pass in the value variable which in this case is "Hip Hop". So you can essentially think of it like this:
public class g1 //We've created an instance of the Genre Class called "g1"
{
private string name;
public string Name
{
get => name;
set => name = "Hip Hop"; //instead of 'value', "Hip Hop" is written because
//'value' in 'g1' was set to "Hip Hop" by previously
//writing 'g1.Name = "Hip Hop"'
}
}
It's Important to note that the above example isn't actually written in the code. It's more of a hypothetical code that represents what's going on in the background.
So now that we've set the Name of the g1 instance of Genre, I believe we can get the name by writing
console.WriteLine (g1.Name); //This uses the 'get' function from our 'Name' Property
//and returns the field 'name' which we just set to
//"Hip Hop"
and if we ran this we would get "Hip Hop" in our console.
So for the purpose of this explanation I'll complete the example with outputs as well
using System;
public class Genre
{
public string Name { get; set; }
}
public class MainClass
{
public static void Main()
{
Genre g1 = new Genre();
Genre g2 = new Genre();
Genre g3 = new Genre();
g1.Name = "Hip Hop";
g2.Name = "Rock";
g3.Name = "Country";
Console.WriteLine ("Genres: {0}, {1}, {2}", g1.Name, g2.Name, g3.Name);
}
}
Output:
"Genres: Hip Hop, Rock, Country"
Those are automatic properties
Basically another way of writing a property with a backing field.
public class Genre
{
private string _name;
public string Name
{
get => _name;
set => _name = value;
}
}
It 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.
You could just make your data members public without using this shortcut but then if you decided to change the implementation of the data member to have some logic then you would need to break the interface. So in short it is a shortcut to create more flexible code.
This is the short way of doing this:
public class Genre
{
private string _name;
public string Name
{
get => _name;
set => _name = value;
}
}
Basically, it's a shortcut of:
class Genre{
private string genre;
public string getGenre() {
return this.genre;
}
public void setGenre(string theGenre) {
this.genre = theGenre;
}
}
//In Main method
genre g1 = new Genre();
g1.setGenre("Female");
g1.getGenre(); //Female
Basically it helps to protect your data. Consider this example without setters and getter and the same one with them.
Without setters and getters
Class Student
using System;
using System.Collections.Generic;
using System.Text;
namespace MyFirstProject
{
class Student
{
public string name;
public string gender;
public Student(string cName, string cGender)
{
name = cName;
gender= cGender;
}
}
}
In Main
Student s = new Student("Some name", "Superman"); //Gender is superman, It works but it is meaningless
Console.WriteLine(s.Gender);
With setters and getters
using System;
using System.Collections.Generic;
using System.Text;
namespace MyFirstProject
{
class Student
{
public string name;
private string gender;
public Student(string cName, string cGender)
{
name = cName;
Gender = cGender;
}
public string Gender
{
get { return gender; }
set
{
if (value == "Male" || value == "Female" || value == "Other")
{
gender = value;
}
else
{
throw new ArgumentException("Invalid value supplied");
}
}
}
}
}
In Main:
Student s = new Student("somename", "Other"); // Here you can set only those three values otherwise it throws ArgumentException.
Console.WriteLine(s.Gender);
Its an auto-implemented property for C#.
The get/set pattern provides a structure that allows logic to be added during the setting ('set') or retrieval ('get') of a property instance of an instantiated class, which can be useful when some instantiation logic is required for the property.
A property can have a 'get' accessor only, which is done in order to make that property read-only
When implementing a get/set pattern, an intermediate variable is used as a container into which a value can be placed and a value extracted. The intermediate variable is usually prefixed with an underscore.
this intermediate variable is private in order to ensure that it can only be accessed via its get/set calls. See the answer from Brandon, as his answer demonstrates the most commonly used syntax conventions for implementing get/set.
They are the accessors for the public property Name.
You would use them to get/set the value of that property in an instance of Genre.
That is an Auto-Implemented Property. It's basically a shorthand way of creating properties for a class in C#, without having to define private variables for them. They are normally used when no extra logic is required when getting or setting the value of a variable.
You can read more on MSDN's Auto-Implemented Properties Programming Guide.
This mean that if you create a variable of type Genre, you will be able to access the variable as a property
Genre oG = new Genre();
oG.Name = "Test";
In the Visual Studio, if you define a property X in a class and you want to use this class only as a type, after building your project you will get a warning that says "Field X is never assigned to, and will always has its default value".
By adding a { get; set; } to X property, you will not get this warning.
In addition in Visual Studio 2013 and upper versions, by adding { get; set; } you are able to see all references to that property.
Its basically a shorthand. You can write public string Name { get; set; } like in many examples, but you can also write it:
private string _name;
public string Name
{
get { return _name; }
set { _name = value ; } // value is a special keyword here
}
Why it is used? It can be used to filter access to a property, for example you don't want names to include numbers.
Let me give you an example:
private class Person {
private int _age; // Person._age = 25; will throw an error
public int Age{
get { return _age; } // example: Console.WriteLine(Person.Age);
set {
if ( value >= 0) {
_age = value; } // valid example: Person.Age = 25;
}
}
}
Officially its called Auto-Implemented Properties and its good habit to read the (programming guide).
I would also recommend tutorial video C# Properties: Why use "get" and "set".
Such { get; set; } syntax is called automatic properties, C# 3.0 syntax
You must use Visual C# 2008 / csc v3.5 or above to compile.
But you can compile output that targets as low as .NET Framework 2.0 (no runtime or classes required to support this feature).
Get set are access modifiers to property.
Get reads the property field.
Set sets the property value.
Get is like Read-only access.
Set is like Write-only access.
To use the property as read write both get and set must be used.
Get is invoked when the property appears on the right-hand side (RHS)
Set is invoked when the property appears on the left-hand side (LHS)
of '=' symbol
For an auto-implemented property, the backing field works behind the scene and not visible.
Example:
public string Log { get; set; }
Whereas for a non auto-implemented property the backing field is upfront, visible as a private scoped variable.
Example:
private string log;
public string Log
{
get => log;
set => log = value;
}
Also, it is worth noted here is the 'getter' and 'setter' can use the different 'backing field'
A property is a like a layer that separates the private variable from other members of a class. From outside world it feels like a property is just a field, a property can be accessed using .Property
public class Person
{
public string FirstName { get; set; }
public string LastName { get; set; }
public string FullName => $"{FirstName} {LastName}";
}
public class Person
{
public string FirstName { get; set; }
public string LastName { get; set; }
public string FullName { get { return $"{FirstName} {LastName}"; } }
}
FullName is a Property. The one with arrow is a shortcut. From outside world, we can access FullName like this:
var person = new Person();
Console.WriteLine(person.FullName);
Callers do not care about how you implemented the FullName. But inside the class you can change FullName whatever you want.
Check out Microsoft Documentation for more detailed explanation:
https://learn.microsoft.com/en-us/dotnet/csharp/properties
Define the Private variables
Inside the Constructor and load the data
I have created Constant and load the data from constant to Selected List class.
public class GridModel
{
private IEnumerable<SelectList> selectList;
private IEnumerable<SelectList> Roles;
public GridModel()
{
selectList = from PageSizes e in Enum.GetValues(typeof(PageSizes))
select( new SelectList()
{
Id = (int)e,
Name = e.ToString()
});
Roles= from Userroles e in Enum.GetValues(typeof(Userroles))
select (new SelectList()
{
Id = (int)e,
Name = e.ToString()
});
}
public IEnumerable<SelectList> Pagesizelist { get { return this.selectList; } set { this.selectList = value; } }
public IEnumerable<SelectList> RoleList { get { return this.Roles; } set { this.Roles = value; } }
public IEnumerable<SelectList> StatusList { get; set; }
}
Properties are functions that are used to encapsulate data, and allow additional code to be executed every time a value is retrieved or modified.
C# unlike C++, VB.Net or Objective-C doesn’t have a single keyword for declaring properties, instead it uses two keywords (get/set) to give a much abbreviated syntax for declaring the functions.
But it is quite common to have properties, not because you want to run additional code when data is retrieved or modified, but because either you MIGHT want to do so in the future or there is a contract saying this value has to be a exposed as a property (C# does not allow exposing data as fields via interfaces). Which means that even the abbreviated syntax for the functions is more verbose than needed. Realizing this, the language designers decided to shorten the syntax even further for this typical use case, and added “auto” properties that don’t require anything more than the bare minimum, to wit, the enclosing braces, and either of the two keywords (separated by a semicolon when using both).
In VB.Net, the syntax for these “auto” properties is the same length as in c# —- Property X as String vs string X {get; set;}, 20 characters in both cases. It achieves such succinctness because it actually requires 3 keyword under the normal case, and in the case of auto properties can do without 2 of them.
Removing any more from either, and either a new keyword would have had to be added, or significance attached to symbols or white space.
I received the following email today from a co-worker. My question is this accurate. Nesting Business Objects is bad practice? Can anyone shine in on this?
Nested Objects
When any variable is created within C# it takes up a piece of memory on the Web Server. Since we will have many tools running on the same server, it is even more important to ensure we are not creating objects if we don't plan on using them.
Using the second employee object above as an example… If we also needed to know the employees Supervisor ID.. (and that was all the tool was populating and using) we would want to ensure the Employee class contains the appropriate information, along with taking into consideration Memory and Processes in the tool.
We would add the 'supervisorId' string variable to the Employee class, and add the appropriate Getters and Setters.
On the flip side, we would want to shy away from nesting another object within the employee object. Such as:
public class Employee {
private string firstName;
private string lastName;
private string empId;
private Employee supervisor;
public string FirstName {
get { return firstName; }
set { firstName = value; }
}
public string LastName {
get { return lastName; }
set { lastName = value; }
}
public string EmpId {
get { return empId; }
set { empId = value; }
}
public Employee Supervisor{
get { return supervisor; }
set { supervisor = value; }
}
}
In this case we may not always use the values within the 'Supervisor' instance of the Employee object, but the variables are created in memory. This can have a potentially catastrophic effect on performance.
There are 'some' cases where nesting of objects is necessary:
Example: (Category :: Question) Where each category could have an array list of questions assigned to it.
The short answer to your general question of
Is it bad to nest business objects?
is no.
The long answer is that is sounds like your team is suffering from premature optimization. You need to design your business objects to mirror your business domain. All the behaviors in your business domain should be exemplified in your business layer. Once you've achieved that goal, you can then do performance testing. Actually measure what parts of your system is too slow, and then optimize those parts. Don't get caught up in preoptimizing your business logic before you've even had a chance to get it laid out.
Design and implement, then performance test and then optimize when you find unacceptable slowness.
My opinion is that you should nest only when you'll be routinely calling a method on the nested object.
If all you will do with the nested object is to get some properties of it, then you shouldn't have it nested and should store the properties directly.
It appears from your code sample that you're setting the supervisor Employee object externally (i.e. through the property setter), so I think this design is OK. If you were automatically instantiating the supervisor object (by, say, hitting the database) every time you created the "outer" Employee object, you would have a potential problem.
I believe the following Business Object (Data Transfer Objects) sparked the email:
/// <summary>
/// Manufacturer Data Transfer Object
/// </summary>
public class MfgBO {
public int Id { get; set; }
public string Name { get; set; }
public bool Active { get; set; }
}
}
public class TypeBO {
public int Id { get; set; }
public string Name { get; set; }
public bool Active { get; set; }
}
public class ModelBO {
#region Private Variables
private int mmtId = -1;
private int id = -1;
private string name = String.Empty;
private bool active = false;
private MfgBO mfg = new MfgBO();
private TypeBO type = new TypeBO();
#endregion
// Getter and setters below
Looking at this the ModelBO holds the MfgBO and a TypeBO because a model cannot be complete without the info. What he is recommending is in the ModelBO instead of having MfgBO or TypeBO, we should have a variable of int MakeID, string MakeName, int DeviceTypeId, string DeviceTypeName, etc, basically retyping fields that already exist in MfgBO and TypeBO objects.
To my limited OOP knowledge it makes more sense to use the MfgBO and TypeBO. Which is better way for my own personal knowledge? Is having the MfgBO and TypeBO in MakeBO will actually use more memory and "potentially crash the server"?
You could create the object only if you explicitly access it.
public BusinessObject Item
{
get
{
if (_Item == null)
_Item = new BusinessObject();
return _Item;
}
}
private BusinessObject _Item;
I need some help/guidance on WinForms data binding and I can't seem to get Google to help me with this one.
Here is my scenario. Consider the following classes which is similar to what I need:
public class Car
{
public string Name { get; set; }
public List<Tire> Tires { get; set; }
}
public class Tire
{
public double Pressure { get; set; }
}
My instances of this will be an object of class Car with a List with four Tire objects. Note that I will always have a known number of objects in the list here.
Now I want to data bind this to a Form containing five textboxes. One textbox with the name of the car and one textbox with each of the tires pressures.
Any idea on how to make this work? The designer in VS does not seem to allow me to set this up by assigning to list indexes like Tires[0].Pressure.
My current solution is to bind to a "BindableCar" which would be like:
public class BindableCar
{
private Car _car;
public BindableCar(Car car)
{
_car = car;
}
public string Name
{
get { return _car.Name; }
set { _car.Name = value; }
}
public double Tire1Pressure
{
get { return _car.Tires[0].Pressure; }
set { _car.Tires[0].Pressure = value; }
}
public double Tire2Pressure
{
get { return _car.Tires[1].Pressure; }
set { _car.Tires[1].Pressure = value; }
}
public double Tire3Pressure
{
get { return _car.Tires[2].Pressure; }
set { _car.Tires[2].Pressure = value; }
}
public double Tire4Pressure
{
get { return _car.Tires[3].Pressure; }
set { _car.Tires[3].Pressure = value; }
}
}
but this becomes really ugly when my lists contains 20 instead of 4 objects, and for each of those objects I want to bind against 6 properties. That makes a huge "BindableObject"!
You should note that you can bind controls to any object type that implements the interfaces IList, ICollection or IEnumerable or inherits from classes that implement these interfaces. Generic collections also qualify for this kind of binding.
These are internally converted to an IBindingList instance.
Check out the following links for more information:
Roadmap for Windowsforms databinding - Takes a very comprehensive look at the implementation and possibilities and provides a variety of links to other KB articles.
Winforms Object binding - Rockford Lhotka's article on the subject. Provides a Windows forms designer-oriented way of implementing databinding.
Databinding with Windows forms 2.0 - This book by Brian Noyes explores various aspects of Databinding, both in complex and simple scenarios.
While the WinForms designer may not let you do this, have you tried setting up the binding in code? I imagine there is no problem binding a textbox to someCar.Tires[1].Pressure.
I often have a situation like this when creating simple data objects. I have a property called Label that should have a default based on the Name of the object. So if no label is set then the Name is used otherwise use the set Label. A simple example in C#
public class FooBat {
public string Name { get; set; }
public string Label {
get {
if (_label == null) return Name;
return _label;
}
set { _label = value; }
}
}
Now the problem is if you want to edit this object you can't just bind to the Label property or you will get the default value and it will look as if there is a value there when there really isn't. So what I end up doing is create another, read-only property that does the defaulting and I use that is all instances except for when the base object is being edited. This leads to many extra properties with weird names like LabelWithDefault. Another alternative I've tried is to make Label handle the defaulting and make a new property called RealLabel that is used for editing the base object. This is just as bad.
I've thought of moving the defaulting code somewhere else but I haven't found a good place for it in any "normal" model that does not replicate the defaulting code many times.
What I have started to do now is initialize the Label field when the Name field is set (and the Label field is not) and then treat the Label field as a normal field. This works but now the code for defaulting is tied to the wrong property. Why should the Name know that the Label field cares about it? So this is also not "right."
Does anyone have any better ways of handling this problem?
I think there is a little confusion about what I'm asking for. Basically I need two different views to the same object for two different uses. In the first is the editing of the object itself where I want unset fields to show as empty (unset). The second is for all other cases (including when the object is the value of a field of another object) where I want to show each field with its dynamically determined default. Just setting the default the first time doesn't no help because if the (in this case) Name field changes then the Label field must also change until the Label field is set.
The answers are getting closer but I still think that they are too targeted to the example I gave. I was trying to give a concrete example for expository purposes but in reality this is more of a best-practices issue. The example I gave was C# and for a string property but I have the same problem with most languages and systems that I use that have frameworks where the data access and data display are handled for you as well as for data types other than strings. Changing the object that is queried from the data source is possible but often tricky and knowing when to make the change (use a sublclass in this case but not in that one) is particularly difficult.
public class FooBat {
public string Name { get; set; }
public string Label {
get {
if (_label == null)
_label = Name;
return _label;
}
set { _label = value; }
}
}
Regarding your update:
You could subclass your object. The base-class would return null if the field has not been set and the sub-class would return your default value. Thus if you need to query if a value has been set, you would cast to the base-class.
Deleted previous answers/updates for brevity.
Update 2:
I would have to say the best way is to track whether the property has been set or not with an IsPropertySet bool. The Getter for the property would check that value to see if it should be returning its own value or the default value. And the setter for the property would set the IsPropertySet according to the set value (true if the value is not null, false if it is). The code that is using the class could then look at the IsPropertySet value to determine if it is receiving a set value or the default when it calls the Property's Getter.
public class FooBat {
public string Name { get; set; }
public bool IsLabelSet { get; set; }
public string Label {
get {
if (IsLabelSet)
return _label;
else
return Name;
}
set {
IsLabelSet = value != null;
_label = value;
}
}
}
I use a Nameable interface a lot (with getName()). Before I start, I'll suggest that you don't want to do this at all. It should be the domain of your display logic, not your domain objects. Usually it's the code consuming the FooBat that is able to make this decision in a better way than the object itself. That aside...
public interface Label{
string getLabel();
boolean isDefault(); //or isValued() or use instanceof expressions
}
public interface Nameable{
string getName();
}
public class FooBat implements Nameable {
public string Name { get; set; }
public Label Label {
get {
if (_label == null) {
_label = new DefaultLabel(this);
}
return _label;
}
set { _label = value; }
}
}
public class DefaultLabel implements Label{
public DefaultCharSequence(Nameable named){
this.named = named;
}
public string getLabel(){
return named.getName();
}
public boolean isDefault(){ return true; }
}
public class StringLabel implements Label {
...
}
It all essentially boils down to returning a better class for your label object.