Personally, I think I am still in the process of making the final paradigm leap to generics. It will probably be some time yet before I am satisfied that I am applying the concept creatively enough in the early design phase. The end goal is to become comfortable enough with the new syntax to "genericize" my code and make it more type-safe and reusable overall.

Right now, a lot of people are overly-occupied with the latest 3.5 toys. If it ain't SilverLight or MVC it ain't worth talking about. It pays to concern oneself with the basic building blocks that make up the language of your choice. In my case, it is C# although I used C++ right through college and spent some time with Java. The point is that in an object-oriented world, such concepts as generics travel quite well across languages and underpin the development of a strong object view of things overall. The "drag and drop brigade" frequently have a problem grasping this.

Generics operate at the compiler level. It was necessary to change the metadata, compiler and IL instructions to make it all posssible. The upshot is that generics work across different .NET managed languages. This means that we can define a generic class in C# and consume it in VB. Score another one for code reuse :-)

Under the hood, the compiler generates the intermediate language (IL) which contains placeholders for the actual types which will be substituted at runtime. In other words, the generic types are "instantiated" at runtime. This is known as "lazy" specialization or "just-in-time". The accompanying metadata is used for compile-time type-checking and intellisense.

It is possible that code could try to use types which are not compatible with what was intended and "contraints" are provided as a measure of protection to prevent this happening. Remember, a generic class or method knows nothing about the arguments being passed to it. The compiler needs to know something more. Each type parameter can have a different set of constraints, expressed using a where clause. A parameter can have multiple constraints, separated by commas.

class Guitar < T1, T2, T3>
    where T1: Fender
    where T2: Gibson
    where T3: Martin
{
    ...
}

To recap, you will most likely find a use for generics with collections. It is well worth the time invested. Right now, I'm working my way through a copy of Professional .NET 2.0 Generics by Tod Golding. It's about the best book on the topic of Generics that I have come across. Happy coding!

I'm going to keep this as simple as possible. Your main goal is to gain an appreciation of why we would want to use generics in the first place. The typical candidate scenario for the use of generics is where we have a class that has a member variable, and the type of this variable should be defined by the client of the class, and not by the programmer. Likewise, for a method that has a parameter passed to it. In other words, the code in our classes and methods remains the same and the types of the data can change with each use. Think code reuse.

Up to now, this type of generality involved writing the same code over and over for each type you wanted to accomodate. And with collections, you would typically have to use the object class and then cast back. This would involve boxing and unboxing for value types, which would incur heavy performance hits, depending on the size of your collections. More importantly, when casting back, you could not be certain of the type in the collection. This could result in runtime errors after your code had shipped. More than anything else, the type safety afforded by generics is its biggest selling point. Type-safe code is the easiest code to maintain, plain and simple.

With generics, we declare type-parameterized code which we can instantiate with different types. We write the code with '<T>' placeholders for types and then plug in the actual types when we are creating an instance. We don't have to use the letter 'T', it's just convention.

// 1.1 Loosely-Typed Collection
Class Stack
{
  public object Pop();
  ...
}

Stack s = new Stack();
s.Push(1);
s.Push(2);

// Cast necessary
int i = (int) s.Pop();

// 2.0 Strongly-Typed Collection
Class Stack<T>
{
  public <T> Pop();
  ...
}

Stack<int> s = new Stack<T>();
s.Push(1);
s.Push(2);

// No cast necessary
int i = s.Pop();

You'll probably find the most ready use for generics when implementing collections. The generic collection classes are part of the C# 2.0 System.Collections.Generic namespace. Below is a list of the traditional 1.1 collections and their new 2.0 equivalents (from Krzysztof Cwalina):

In the next part, I'll try and cut through the jargon attached to generics and also discuss some practical uses for generics in everyday coding tasks. In the meantime, check out this excellent Overview of Generics in the .NET Framework.

They say the best developers are lazy. I used to believe this and would cite code reuse as justification for my inertia! For a long time now, I have been intending to use generics and collections more in my code. I guess I meant well, but in the real world we tend to go for what we know works and a syntax that we feel comfortable with. There are so many new additions to the C# langauge now that it is tempting to want to jump in and play. However, I feel that a grasp of generics is an important skill to acquire first. So, I'm going to take a walk through the generics landscape and see how it all fits together...

Here's a loose definition from a Microsoft MSDN article: "Generics are the most powerful feature of C# 2.0. Generics allow you to define type-safe data structures, without committing to actual data types. This results in a significant performance boost and higher quality code, because you get to reuse data processing algorithms without duplicating type-specific code. In concept, generics are similar to C++ templates, but are drastically different in implementation and capabilities."

Generics permit us to write code where the data types aren't hard-coded. If we have a lot of code that performs the same function but on different types, then we can get big savings in terms of performance and the amount of code that we actually have to create.

Let me say two things about generics right off the bat: first, the main motivation for generics is not one of performance. Performance is more of a side effect, if you will. It is more about what the name implies, that is, it gives a level of generality to our types. It helps us to factor out the behaviour of our classes from the data upon which they act. In addition to performance gains, we profit from increased code reuse and type safety. Second, although they share a similar motivation, generics and templates are fundamentally different animals: generics are created at runtime by the CLR and templates are created at compile time by the compiler.

The designers of generics define it as "a feature that permits classes, structures, interfaces, delegates, and methods to be parameterized by the types of data they store and manipulate." The goal of this series is to demystify generics and to encourage you incorporate it into your own code, even if only in a very basic way to begin.

In the next part, we'll take a look at some specifics including where we can use generics and and how to find our way through the new terminology associated with generics. We'll save 'Parametric Polymorphism' for a later installment ;-)

As promised, here's the final installment. You can find the download links for the final version of the code at the end of this article. Feel free to use this code and tweak it any way you wish. For demo purposes, the menu is on all the pages but you can easily factor this out into its own form. I would normally make this a separate control, but you will probably be integrating this application into your existing navigation anyway, so...

The membership system in ASP.NET 2.0 is pretty much plug-and-play right out of the box. When I worked with it first, I took some time to read up on the new membership controls before trying them out. For this particular topic, I cannot recommend the following two books highly enough:

* Murach's ASP.NET 2.0 Upgrader's Guide (Lowe & Murach)
* Pro ASP.NET 2.0 in C# 2005 (MacDonald & Szpuszta)

Just to recap, at this point you should have a working Guest Book application and database. The only thing left to do is to configure the membership system and add some administration forms to allow us to edit, update, delete and publish comments posted by users.

The next item on our list is to use the WSAT tool to add an admin user, create the admin role and add the new admin user to that role. By using a role, we can grant extra privileges to admin users in the future if needed. We can just do it once rather than having to grant them to each admin user individually. A picture is worth a thousand words, so please refer to the pics for guidance.

Access the WSAT by clicking on the icon at the top of Solution Explorer in VS 2008. Note that the administrator role is already set up in the config file and all you have to do is add the admin user to this role. I'm including a picture showing how to set up the access rule using the tool. The main problem people encounter here is the order of the entries in the authorization section of the config file. The administrator role is listed before 'users'. See the config file picture in part II of this series for clarification.

We will add a new form called guestBookAdmin.aspx to the Admin folder which shows a list of the comments awaiting moderation in a GridView. Clicking on one of these brings up the commentDetails.aspx form. This is almost a replica of the addComment.aspx form which is populated with the data for this comment. The comment ID is passed to this new form when the 'select' link on the guestBookAdmin form is clicked. This is then used as a parameter to the stored procedure when fetching the data for this comment. Note also, that there is now a 'publish' check box. The administrator uses this to put a comment live after it has been edited and approved.

Just a few words about the ObjectDataSource control here. This is an amazingly helpful control which we can use to create a declarative link between our front-end Web controls and our data access methods. Note that our data access class must have a default, parameterless constructor and none of the select or update methods can be static. This is just another reason why I prefer to inject a business layer between the front and back-ends. It gives us a nice comfort zone for future code customizations in the shape of new business rules and the like. Plus, we get to use a more friendly syntax. Ideally, each record should be a custom object but that's another story!! Bring on the new Entity Framework :-)

Be sure to check out the brand new security video tutorials from Scott Mitchell.

Download Code:

GuestBook.zip (99.61 kb)

GuestBook-DB.zip (1.01 kb)

You can also view part I of this article which describes the setting up of this application with Visual Studio 2008 and IIS 7, running on Vista. SQL Server 2005 was used as the database. I had originally blogged on this using VS 2005 but feedback indicated that quite a few people are now using VS 2008, so I upgraded it to VS 2008, which I am currently running on VMWare Workstation... the best $190 I ever spent. This is part II and the full code will be available for download in part III, real soon!

Speaking of feedback, I have been having problems with the comments system on this blog for some time now. So, pretty soon I am upgrading the blog engine and switching to a database version. The plan is to eventually make it a real "Community" site. Watch this space...

The Guest Book application is written in C# and is pretty straightforward. Here I will walk through the creation of the back-end which will allow the site administrator to moderate the comments posted to the guest book by site visitors.

First, we need to set up our membership system. The membership system is where most people seem to get stuck. There are several ways of achieving the same thing and I think that this is what causes much of the confusion. Typically, in an application such as this you would use a CAPTCHA control to combat the spammers, so we are not going to force users to register in order to sign the guest book. We will need an administration area for our admin forms, so we will create an "admin" role. The way I go about this is to create a new folder and call it Admin. Add a config file  to this new folder and set up the authorization rules as shown below.

Now, we're going to cheat a little. I'm going to do the TV chef and slip in a little something I pre-prepared earlier in the kitchen (actually gleaned from several of Scott Guthrie's blog postings). I always keep a sample Web.config file handy that I know is set up correctly for a basic membership system. I start this way rather than jumping in right off with the WSAT wizard because I want to have one single database for both my application and membership data. Tidier. So, I manually set up the database connection in the project Web.config file, along with entries for the membership and authentication sections. See the snippets below, and don't forget to include the roleManager tag!

Now that the membership database connection is configured the way we want it, we can run the aspnet_regsql tool from the command line. This will create the actual membership database objects for us as part of our Guests database. Just navigate from the start menu to SQL Server Management Studio and locate the command line tool under the Configuration Tools folder. Simply enter aspnet_regsql at the prompt and you will be presented with the SQL Server Setup Wizard. Here are some screenshots showing the correct selections to make:

If you go to SSMS and refresh the database, you should now be able to expand the tables icon, and you will see that the wizard had created everything we need for our membership system. At this stage, you are ready to run the WSAT tool and start setting up the admin role and adding the admin user. I will outline this process in the final installment, as well as the creation of our administration forms. Stay tuned!