We'll be at Desert Code Camp This Weekend

Matt — Fri, 14 Sep 2007 16:58:59 GMT

Should have gotten the word out sooner, of course, but better late than never - right. Bennie and I've been cramming a bit: it's been an exercise in designing an enterprise .NET 3.x reference architecture in about a week and a half while juggling the clients and family commitments. Well - truth be told the: I'll have to do something special for the wife and boys after this...

What Are You Talking About?

Bennie and I are presenting the Building an Enterprise App with .NET 3.x from the Application Design track at Desert Code Camp 2007 in Tempe Saturday morning. As a heads-up we don't know how Acropolis and Silverlight got on the description: we won't be covering those technologies as exciting as they are.

The track will, however, cover a vertical slice of a web based Events planning reference application. The intent is to highlight how to go about tackling an enterprise or mission critical requirement given the mix of new technologies and tools in .NET 3.x and Visual Studio 2008 and to discuss recommendations for designing, developing and maintaining such applications. We'll specifically discuss Windows Presentation Foundation (WPF), Windows Workflow Foundation (WF) used as a controller for the user interface as well as to control and represent the "long-running" sometimes complicated process, Windows Communication Foundation (WCF) which provides a message based services infrastructure that is easily extended, maintained and scaled, and the brand new .NET 3.5 feature Linq (Linq to SQL in particular) as the resource access layer within the service architecture.

This reference architecture will be the subject of subsequent posts on Foo Theory and we've discussed, perhaps, collaborating with the broader community once it matures.

Bennie will also be presenting (or teaching as they call it) two other tracks this weekend:

The new C# Features behind Linq - Saturday
Intermediate PowerShell - Sunday

Hope to see you at code camp. It looks like the tracks are close to capacity so if you don't make it stay tuned at Foo Theory for more news.

Technorati tags: .NET 3.0, .NET 3.5, AZ Groups, Desert Code Camp, Windows Presentation Foundation, Windows Workflow Foundation, Windows Communication Foundation, Linq

New Features in C# 3.0, Part 3: Automatic Properties, Object Initializers and Collection Initializers

bennie — Fri, 03 Aug 2007 06:05:43 GMT

Introduction

This post does not focus on one particular new feature is the rich new feature set of C# 3.0, but rather studies a set of features, which are loosely related, and play a roll in the enablement of LINQ in the .NET 3.5 framework, which is ultimately the focus of this series of posts.

In this post, we will study the following topics:

Automatic properties. Automatic properties allow you to declare class properties using a very terse syntax, increasing your productivity and reducing the amount of typing that you have to do.
Object Initializers. Object initializers allow you to use a focused, "short hand" notation to initialize the properties of a class.
Collection Initializers. Like object Initializers allow you to use a "short hand" syntax for the initialization of a class, collection initializers allow you to do the same thing for your collections.

Previous posts is this series are:

New features in C# 3.0, Part 1. This part focuses on implicitly typed local variables
New Features in C# 3.0 Part 2. This post provides some insights into anonymous types.

The code for this feature can be downloaded here.

Ok enough talk, let's have a look at our first "feature of the day": Automatic Properties!

Automatic Properties

Overview

Note: the code for this feature is contained in the "AutomaticProperties" console application of the code.

Everybody has written typical "data container" classes before. These are the typical classes which contains simple fields, and properties with both a getter and a setter for each fields. And every develop I know simply HATES writing these things, because they are what I call "monkey code", code that could be written by semi-intelligent primates (or even a project manager ;-).

Below are some simple examples of such classes:

 1 namespace AutomaticProperties.Classic
 2 {
 3     /// <summary>
 4     /// This is our "classic, old style" CoffeeShop class
 5     /// </summary>
 6     public class CoffeeShop
 7     {
 8         private string _shopName;
 9         private Address _address;
10         private decimal _priceOfLatte;
11         private string _baristaName;
12 
13         public string ShopName
14         {
15             get
16             {
17                 return _shopName;
18             }
19             set
20             {
21                 _shopName = value;
22             }
23         }
24 
25         public Address Address
26         {
27             get
28             {
29                 return _address;
30             }
31             set
32             {
33                 _address = value;
34             }
35         }
36 
37         public Decimal PriceOfLatte
38         {
39             get
40             {
41                 return _priceOfLatte;
42             }
43             set
44             {
45                 _priceOfLatte = value;
46             }
47         }
48 
49         public string BaristaName
50         {
51             get
52             {
53                 return _baristaName;
54             }
55             set
56             {
57                 _baristaName = value;
58             }
59         }
60     } // class AutomaticProperties.Classic.CoffeeShop
61 }
62

 1 namespace AutomaticProperties.Classic
 2 {
 3     /// <summary>
 4     /// This is our "classic, old style" Address class
 5     /// </summary>
 6     public class Address
 7     {
 8         private string _streetName;
 9         private int _streetNumber;
10         private string _city;
11         private string _state;
12         private int _zipCode;
13 
14         public string StreetName
15         {
16             get
17             {
18                 return _streetName;
19             }
20             set
21             {
22                 _streetName = value;
23             }
24         }
25 
26         public int StreetNumber
27         {
28             get
29             {
30                 return _streetNumber;
31             }
32             set
33             {
34                 _streetNumber = value;
35             }
36         }
37 
38         public string City
39         {
40             get
41             {
42                 return _city;
43             }
44             set
45             {
46                 _city = value;
47             }
48         }
49 
50         public string State
51         {
52             get
53             {
54                 return _state;
55             }
56             set
57             {
58                 _state = value;
59             }
60         }
61 
62         public int ZipCode
63         {
64             get
65             {
66                 return _zipCode;
67             }
68             set
69             {
70                 _zipCode = value;
71             }
72         }
73     } // class AutomaticProperties.Classic.Address
74

The code above defines two classes, both of which are in the AutomaticProperties.Classic namespace:

CoffeeShop
Address

Automatic properties allow you to avoid having to manually declare a private field and write the get/set logic -- instead the compiler will automatically creating the private field and the default get/set operations for you. Below are the CoffeeShop and Address classes rewritten using Automatic Properties (note that both classes are in the AutomaticProperties.New namespace):

1     public class CoffeeShop
2     {
3         public string ShopName { get; set; }
4         public Address Address { get; set; }
5         public decimal PriceOfLatte { get; set; }
6         public string BaristaName { get; set; }
7     }

1     public class Address
2     {
3         public string StreetName { get; set; }
4         public int StreetNumber { get; set; }
5         public string City { get; set; }
6         public string State { get; set; }
7         public int ZipCode { get; set; }
8     }

That's it. Note that we went from 100+ lines of code to a grand total of 15!

When the C# 3.0 compiler encounters an empty get/set property implementation like we created above in the CoffeeShop and Address classes, it will now automatically generate a private field for us within our class, and implement a public getter and setter property implementation for it. The benefit of this is that from a type-contract perspective, the class looks exactly like it did with my first (much more verbose) implementation shown above. This means that -- unlike resorting to public fields -- I can in the future add validation logic within my property setter implementation without having to change any external component that references my class.

Usage Example

Now, using "classic" classes, and classes that use automatic properties is completely identical. To provide this, I have included a small piece of client code in the download file, that looks as follows:

 1 using System;
 2 
 3 // Comment out one of the using statements below
 4 // to either use the "Classic" or the "New-Style"
 5 // Automatic Properties-style classes
 6 
 7 using AutomaticProperties.Classic; // uses class classes
 8 //using AutomaticProperties.New;   // uses automatic properties 
 9 
10 namespace AutomaticProperties
11 {
12     class Program
13     {
14         static void Main(string[] args)
15         {
16             Address address = new Address();
17             address.StreetNumber = 50;
18             address.StreetName = "Passover Lane";
19             address.ZipCode = 6703;
20             address.State = "MO";
21             address.City = "Missoula";
22 
23             CoffeeShop coffeeShop = new CoffeeShop();
24             coffeeShop.Address = address;
25             coffeeShop.PriceOfLatte = 3.95M;
26             coffeeShop.ShopName = "It's a Grind!";
27             coffeeShop.BaristaName = "6 Shot Lucie";
28         }
29     }
30 }
31

You can comment out either the "using AutomaticProperties.Classic" or the "AutomaticProperties.New" line, and depending on which "using" line is not commented out, the code will use the classic classes, or the classes with the automatic properties. Note though that the rest of code is unchanged.

There is one interesting thing to try though. If you use the "classic" objects, and you set a breakpoint on a line that sets a property, for example:

and you "Step In" (F11), then you will actually go to the setter of the property implementation, as shown below:

this makes sense, since we provided this setter in C#!

Automatic Properties in detail

Now, when you switch to the "automatic properties" version of the objects, and you set the same breakpoint and you step in, you notice that nothing actually happens, which makes sense, because there is only direct IL code, generated by the compiler behind the setter implementation, and no C# code, so the compiler has nowhere to go!

The easiest way to verify this is to bring out our old friend ILDASM.exe, and open our "automatic properties" version Address class is this tool. It would look something like this:

now, we can compare this to the "classic" style Address class:

The we notice that on the surface things very much look the same. Both classes have their properties, and their getters and setters. BUT the big difference is the the "classic" version has the actual fields as we defined them, while for the "automatic properties" version,the compiler injected a private member variable, prefixed with <k>BackingField, like this one for the City property:

1 .field private string '<City>k__BackingField'
2 .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 )

The CompilerGeneratedAttribute is useful if you have a tool that would like to find out if something is auto-generated. The getter IL implementation look like this:

 1 .method public hidebysig specialname instance string 
 2         get_City() cil managed
 3 {
 4   .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 ) 
 5   // Code size       11 (0xb)
 6   .maxstack  1
 7   .locals init (string V_0)
 8   IL_0000:  ldarg.0
 9   IL_0001:  ldfld      string AutomaticProperties.New.Address::'<City>k__BackingField'
10   IL_0006:  stloc.0
11   IL_0007:  br.s       IL_0009
12   IL_0009:  ldloc.0
13   IL_000a:  ret
14 } // end of method Address::get_City

Note the reference to the backing field in line 9. The setter IL looks very similar:

 1 .method public hidebysig specialname instance void 
 2         set_City(string 'value') cil managed
 3 {
 4   .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 ) 
 5   // Code size       8 (0x8)
 6   .maxstack  8
 7   IL_0000:  ldarg.0
 8   IL_0001:  ldarg.1
 9   IL_0002:  stfld      string AutomaticProperties.New.Address::'<City>k__BackingField'
10   IL_0007:  ret
11 } // end of method Address::set_City

Again note the setting of the backing field at line 9. So, as you can see, the "automatic property" version of the code has NO C# code behind the getters and setters of the properties, which is why we could not step into the code with the debugger.

One last important note: Automatic properties should have both a getter and a setter. If you leave out one of the two, you will get a compiler error like this:

Error    1    'AutomaticProperties.New.Address.City.get' must declare a body because it is not marked abstract or extern. 
Automatically implemented properties must define both get and set accessors.

When you think about it this really makes sense, the whole concept behind automatic properties is to allow you to quickly write typical "data container" or "property bag" classes, which typically have read/write properties.

Object Initializers

Overview

Note: the code for this feature is contained in the "ObjectInitializers" console application of the code.

When we write code that deals with simple objects, we tend to rely heavily on the use of properties. The sample code for this section contains a class named "CarModel" which represents the model of a car. The class is shown below:

 1     public class CarModel
 2     {
 3         private string _make;
 4         private string _model;
 5         private int _year;
 6 
 7         public string Make
 8         {
 9             get { return _make; }
10             set { _make = value; }
11         }
12 
13         public string Model
14         {
15             get { return _model; }
16             set { _model = value; }
17         }
18 
19         public int Year
20         {
21             get { return _year; }
22             set { _year = value; }
23         }
24 
25         public override string ToString()
26         {
27             return String.Format(
28                 "Make: {0}, Model: {1}, Year: {2} ", Make, Model, Year);
29         }
30     }
31

In a typical approach, we would initialize a new instance of this class as follows:

1         private static void CreateCarModelTraditional()
2         {
3             CarModel carModel = new CarModel();
4             carModel.Make = "Acura";
5             carModel.Model = "TL";
6             carModel.Year = 2007;
7             Console.WriteLine("Traditional CarModel: " + carModel);
8 
9         } // method CreateCarModelTraditional

While this is a tried-and-true approach that has served us well for many years, it is very verbose. C# 3.0 now offers a new feature called "Object Initializers", which allows us to write the above code as follows:

1         private static void CreateCarModelWithInitializer()
2         {
3             CarModel carModel = new CarModel {Make = "Acura", Model = "TL", Year = 2007};
4             Console.WriteLine("\nCarModel with Initializer: " + carModel);
5 
6         } // method CreateCarModelWithInitializer

All this is is really "Syntactic Sugar", which at the IL level results in the same code as the tradition approach. Indeed, the compiler will automatically generate all of the property-setter code, which has exactly the same implementation as our first, more verbose example (more in on this in our "In-Depth" section).

Note that Object Initializers will also work with more complex objects, which have nested sub-objects. For example, below is the code for a "Car" class, which contains an embedded "CarModel" instance:

 1     public class Car
 2     {
 3         public CarModel CarModel { get; set; }
 4         public int EngineCC { get; set; }
 5         public int HoursePower { get; set; }
 6         public string Color { get; set; }
 7 
 8         public override string ToString()
 9         {
10             return String.Format(
11                 "Make: {0}, Model: {1}, Year: {2}, \n\tEngineCC: {3}, HorsePower: {4}, Color: {5}",
12                 CarModel.Make, CarModel.Model, CarModel.Year, EngineCC, HoursePower, Color);
13         }
14     }

Note that is this case, I used the more compact "Automatic Properties" approach described in the first part of this post . Indeed Object Initializers work directly with the property setters, so they don't know or care that you used the traditional approach, or the "Automatic Properties" approach to create your properties.

Below is an example of an object initializer for a Car instance:

 1         private static void createCompoundObject()
 2         {
 3             //  Create a Car instance with an initializer
 4             Car car = new Car { 
 5                             Color = "White", 
 6                             HoursePower = 320, 
 7                             EngineCC = 3600, 
 8                             CarModel = new CarModel {Make = "Acura", Model = "TL Type S", Year = 2007}};
 9 
10             Console.WriteLine("\nComplete Car With Initializer: " + car + Environment.NewLine);
11         
12         } // method createCompoundObject

In line 8, you can see how we embedded the initializer for the CarModel directly into the initializer for the Car instance.

Object Initializers in depth

In this section, we will look at the code that is generated by the compiler when we write an object initializer. For example, is we pull out ILDASM (yes, always have that one on your tool belt ;-), and look at the code for the method CreateCarModelWithInitializer(), we see the following:

 1 .method private hidebysig static void  CreateCarModelWithInitializer() cil managed
 2 {
 3   // Code size       63 (0x3f)
 4   .maxstack  2
 5   .locals init ([0] class ObjectInitializers.CarModel carModel,
 6            [1] class ObjectInitializers.CarModel '<>g__initLocal0')
 7   IL_0000:  nop
 8   IL_0001:  newobj     instance void ObjectInitializers.CarModel::.ctor()
 9   IL_0006:  stloc.1
10   IL_0007:  ldloc.1
11   IL_0008:  ldstr      "Acura"
12   IL_000d:  callvirt   instance void ObjectInitializers.CarModel::set_Make(string)
13   IL_0012:  nop
14   IL_0013:  ldloc.1
15   IL_0014:  ldstr      "TL"
16   IL_0019:  callvirt   instance void ObjectInitializers.CarModel::set_Model(string)
17   IL_001e:  nop
18   IL_001f:  ldloc.1
19   IL_0020:  ldc.i4     0x7d7
20   IL_0025:  callvirt   instance void ObjectInitializers.CarModel::set_Year(int32)
21   IL_002a:  nop
22   IL_002b:  ldloc.1
23   IL_002c:  stloc.0
24   IL_002d:  ldstr      "\nCarModel with Initializer: "
25   IL_0032:  ldloc.0
26   IL_0033:  call       string [mscorlib]System.String::Concat(object,
27                                                               object)
28   IL_0038:  call       void [mscorlib]System.Console::WriteLine(string)
29   IL_003d:  nop
30   IL_003e:  ret
31 } // end of method Program::CreateCarModelWithInitializer
32

Now, when we compare this code with the code for the CreateCarModeTraditional():

 1 .method private hidebysig static void  CreateCarModelTraditional() cil managed
 2 {
 3   // Code size       61 (0x3d)
 4   .maxstack  2
 5   .locals init ([0] class ObjectInitializers.CarModel carModel)
 6   IL_0000:  nop
 7   IL_0001:  newobj     instance void ObjectInitializers.CarModel::.ctor()
 8   IL_0006:  stloc.0
 9   IL_0007:  ldloc.0
10   IL_0008:  ldstr      "Acura"
11   IL_000d:  callvirt   instance void ObjectInitializers.CarModel::set_Make(string)
12   IL_0012:  nop
13   IL_0013:  ldloc.0
14   IL_0014:  ldstr      "TL"
15   IL_0019:  callvirt   instance void ObjectInitializers.CarModel::set_Model(string)
16   IL_001e:  nop
17   IL_001f:  ldloc.0
18   IL_0020:  ldc.i4     0x7d7
19   IL_0025:  callvirt   instance void ObjectInitializers.CarModel::set_Year(int32)
20   IL_002a:  nop
21   IL_002b:  ldstr      "Traditional CarModel: "
22   IL_0030:  ldloc.0
23   IL_0031:  call       string [mscorlib]System.String::Concat(object,
24                                                               object)
25   IL_0036:  call       void [mscorlib]System.Console::WriteLine(string)
26   IL_003b:  nop
27   IL_003c:  ret
28 } // end of method Program::CreateCarModelTraditional
29

We note the the ONLY difference between the generated IL is the following:

  .locals init ([0] class ObjectInitializers.CarModel carModel,
           [1] class ObjectInitializers.CarModel '<>g__initLocal0')

The second line in this code block is some bookkeeping for the compiler to remember that Object Initializers were used for this code, but for the rest the code is identical, and the total size of the the general IL is almost the same (61 and 63 bytes), so there is really no overhead in using object initializers.

One case where you need to pay a bit of attention is if you have any object that has a non-default constructor, as show in the example below:

 1     public class Engine
 2     {
 3         public int Horsepower { get; set; }
 4         public int CC { get; set; }
 5 
 6         public Engine(int horsePower)
 7         {
 8             Horsepower = horsePower;
 9         }
10     } // class Engine
11

If you would attempt to use an object initializer in this scenario like this, you will run into some problems:

1         private static void objectWithCtorExample()
2         {
3             Engine engine = new Engine { Horsepower = 120, CC = 2600 };
4         }

Indeed, you will get the following compilation error:


Error    1    'ObjectInitializers.Engine' does not contain a constructor that takes '0' arguments

You have two solutions for this:

Add a default constructor to your class (in all of our previous examples, this default constructor was automatically written for us by the compiler).
Use a syntax that uses the constructor, and uses an object initializer for the remaining properties, as is show below:

1         private static void objectWithCtorExample()
2         {
3             Engine engine = new Engine(120) { CC = 2600 };
4         }

SO, the above code is a bit of a "hybrid" (to use a popular expression -) between the use of constructors and object initializers.

Collection Initializers

Overview

Note: the code for this feature is contained in the "CollectionInitializers" console application of the code.

The concept of Object Initializers can be expanded to collections with C# 3.0. Using a new feature, called "Collection Initializers" you an use a compact syntax to initialize a collection.

For example, take the following class:

 1     public class Dog
 2     {
 3         public string Breed { get; set; }
 4         public string HairColor { get; set; }
 5         public int Weight { get; set; }
 6         public bool IsFriendly { get; set; }
 7 
 8         public override string ToString()
 9         {
10             return String.Format("\tDog: Breed: {0}, HairColor: {1}, Weight : {2}, IsFriendly: {3}",
11                 Breed, HairColor, Weight, IsFriendly);
12         }
13     } // class Dog

in a traditional approach, you could create a collection of dogs as follows:

1         private static void createDogListTraditional()
2         {
3             List<Dog> dogs = new List<Dog>();
4             dogs.Add(new Dog {Breed = "Great Dane", HairColor = "Fawn", Weight = 165, IsFriendly = true});
5             dogs.Add(new Dog { Breed = "Mud", HairColor = "DirtyBlack", Weight = 15, IsFriendly = false });
6 
7         } // method createDogListTraditional
8

So, here we do what we always do, we create a collection, and then add new instances to the collection. The approach with a collection initializer results in more compact code, as is shown below:

1         private static void createDogListCollectionInitializer()
2         {
3             List<Dog> dogs = new List<Dog>() {
4                 new Dog { Breed = "Great Dane", HairColor = "Fawn", Weight = 165, IsFriendly = true },
5                 new Dog { Breed = "Mud", HairColor = "DirtyBlack", Weight = 15, IsFriendly = false }
6             };
7 
8         } // method createDogListCollectionInitializer
9

So, we no longer need the "dogs.Add", statements, and our code looks more natural and compact.

Collection Initializers in depth

I looked at the generated IL code in ILDASM, and the code sizes for each of the methods was as follows:

CreateDogListTraditional(): 128 bytes
CreateDogListCollectionInitializer(): 130 bytes

So again, there is no noticeable overhead in using collection initializers in your code, and I would greatly recommend that you do so to improve the readability of your code.

Conclusion

I hope this article provided you with a good overview of automatic properties, object initializers and collection initializers. These 3 features are used in every LINQ query, and are actually also very useful when you are writing regular production code.

In our next post, we will look at C# 3.0 lambda expressions, which go directly to the core of the how LINQ expressions are generated by the compiler.

Technorati Tags: C# 3.0, LINQ

Search results matching tags '.NET Framework' and 'Linq'

We'll be at Desert Code Camp This Weekend

What Are You Talking About?

New Features in C# 3.0, Part 3: Automatic Properties, Object Initializers and Collection Initializers

Introduction

Automatic Properties

Overview

Usage Example

Automatic Properties in detail

Object Initializers

Overview

Object Initializers in depth

Collection Initializers

Overview

Collection Initializers in depth

Conclusion