Some of C# 3.0's new features

C# 3.0 provides many new technologies, recently I became aware of some of the syntax improvements. This post is intended to outline some of the highlights.

Auto Implemented Properties
One new feature in C# 3.0 is “Auto Implemented Properties”, this is a fancy way of saying that we no longer have to create the private property and the public fields when we write new classes. Take a look at the below example:

private string userId;
Public String UserId
{
get { return userId; }
set { userId = value; }
}

IS the same as

public string UserId {get;set;}

The compiler will write out the needed getters and setters, however, they need not be in the source code unless a more complex structure is needed. The net effect is 5 less lines of code per property.

Object initializers
Another new feature is known as “Object Initializers”, this is a means to allow programmers to set values that aren’t part of the constructor at init time. Take a look at the below example:
Customer c = new Customer(“john”,”doe”);
c.phone=”123-456-7890”;
c.zip = “43534”;

is the same as

Customer c = new Customer(“john”,”doe”) {phone=”123-456-7890”,zip=”43534}

This may seem insignifigant, however, it is not. There are many classes I have come in contact with that have properties that aren’t set in the constructor. In these cases you must make additional statements to set the further needed properties. That limitation is now removed, you can now set those properties all at once. This again, it a little compiler trickery, at compile time they are broken out into individual statements just as you would have, but as with the auto implemented properties, this is an improvement in the overall readability, serviceability, and cleanliness of the source code. I a way this reminds me of how you can add items into an array at the time of declaration
string[] x = new string[]{“a”,”b”,”c”};

Local Variable Type Inference
Microsoft has seen the complaints that the following just looks a little odd:
Customer customer = new Customer();
Their answer is called local variable type inference using the var keyword. What this means that the following will now be accepted:
var customer = new Customer();
In this case the compiler detects the type from the new Customer() part of the statement. I cant say this is a whole lot shorter or neater in most case, however, when using linq, the type is not known as types are created on the fly to support the data requested. So it does seem to be useful in the linq arena.

More thoughts as they come in.

LINQ to SQL Overview" video

From TechEd Barcelona,
This presentation from Luca Bolongnesa is heavy on the Italian accent, but also heavy on content. This is probably the best video, podcast, or article I have read to date on Linq to SQL. Luca covers

• how the Linq to SQL engine works, explaining in depth scenarios, and demonstrating the sql that was executed.
• How joins and aggregation are accomplished
• Stored Procedures
• Optimistic Concurrency and Pessimistic Concurrency
• Transactions both distributed and non distributed

System.Collections.Generics - Dictionary

So, I have wanted to dive into the world of generics for some time now. I have read and read about the stack, queue, and the dictionary classes but just didnt have a need until now. recently on project foo, the need to use an "anchor" that would never change and get back the current display text was presented. I considered my options, we could query for each value... No, there would be many many instances of this need on the same page, and though stored procs are fast, I felt that would be clumsy. Then a light came on, use the dictionary object.

I tried to take it a step farther and use a linq query and the todictionary extension method, to create my dictionary, unfortunatly this went nowhere. I was able to write the needed statement for the linq query, but had many problems with the todictionary method. I suspect it is partly because i am new to both generics and linq. I found that there were few good examples of how to use the todictionary method that I could reference, so I ended up doing it the old fashon way, creating a dataset, then creating a dictionary, and finally itterating over the dataset/datatable and adding each record.

LINQ to SQL and Datacontexts

At first I thought LINQ to SQL was going to be as simple as creating a datacontext, adding all tables to it and then linq away. After some work and some research, I have discovered that though that did work a little more thought is required. For one, what happens if the database schema changes, would the datacontext be updated? Second, should I have a global all encompasing datacontext or would there be a performance cost?


Most of the how-to's and chapters in books i have read do not really cover this, they simply explain how to setup a new datacontext and then how to begin "linqing". I did a little research and discovered that the data context does not get updated when you make changes to the database schema.

So what is the right way to do this, what should go where, and when? One article i found on the subject can be found at http://www.west-wind.com/weblog/posts/246222.aspx . This article by Rick Strahl a Microsoft MVP, suggests the a global datacontext be avoided. After reading several articles on the matter I am inclined to go with a datacontext per thread. This relitively easy to implement, and circumvents the issue he discusses with the global data context forcing all users to updates at one time. I still, havent found any discussion as to weather the whole database should be modeled in a single context or if seperate contexts should be created to hold logical groups of tables. Additionally, I have yet to see any real discussion on the issue that happens if the database schema changes.


There is a code camp coming up on 6/7/2007 and I plan to follow the linq track exclusively.

Refractor SQLGateway Class to Linq

Currently the SQLGateway class is the most confusing and difficult file in the entire system to manage. Unfortunately, it is also the one files that every other file must interact with as it is just as the name states, the gateway to the database. I have held off on this for some time as I wanted to make sure I understood as much as I possibly could about what was being done and what could be done instead.
Here are my conclusions:
1. This class was developed with the intention of abstracting the data layer from the business layer. This is a fantastic idea, in that it can provide a means for reusing queries, and provide a central point of change should the system ever need to be ported over to another DBMS such as Oracle. This follows the spirit of what we as programmers have been taught to do, but were never able to accomplish since the very beginning.
2. Though the idea of providing a single point of change should we use another DBMS is here, it would be impossible in practice to actually accomplish the needed changes to 6100 lines of code along with the other supporting classes, interfaces, and stored procs in any reasonable amount of time.
3. This highly overblown abstraction makes it extremely difficult and time consuming to add new features such as new objects/tables or even new fields as there are about 10 places that need to be updated for each,
4. When the system was initially developed there was obviously a decision made that dictated that all forms of CRUD (insert, update, delete, and select) would be implemented for all data objects. I find this to be a security risk, but beyond that it is very unnecessary. Perhaps the SQLGateway class was generated, and not to be edited by hand, it sure seems so.
5. These standards and techniques were developed to support a .net 1.1 application and thus are subject to review as many years have passed and the app is now under .net 3.5
6. .net 3.5 offers a new technology known as linq or language integrated query. This new data access methodology, provides a 1-3 line interface to the database through ORM (object relational mapping). This interface also provides a parameterized approach which is the number 1 reason for using stored procs, as if additional programming is needed ala a stored proc it still offers these as methods od the data object it creates. Behind the scenes linq creates a data class to mode each entity/table in the database, thus providing the abstraction called for in the 3 tier environment.

I plan to use linq instead of and in place of the current data model wherever possible, Since this application is already quite developed, meaning there is already a large system in place, and the team and myself are all a little new to linq, I plan to implement a 4 tier environment. 1 UI layer (already provided), 1 business layer ( already provided), and 2 data layers stacked. The first will be the existing SQLGateway class and its supporting cast. The second data layer will be interacted with through the first. This means all the existing data methods in the SQLGateway class will remain, and will return what they always have, however inside them, as time permits, I will adjust them to use linq instead of the traditional stored proc setup. This change, along with removing unneeded methods to update, insert, and delete system table data will in my calculations reduce the size of the SQLGateway class by 50%, increase productivity among our team, and still offer every bit of the value of the old model.

First Entry

This blog will be a way of documenting and colaborating within the department about what we have and are still learning in the .net world.

As this blog is dedicated to Asp.net I thought I'd start off by mentioning, if you havent already been there you should surf http://www.asp.net/ This is a fantastic site for information, and has great free how-to videos (direct link) http://www.asp.net/learn/. These videos are better than those from learnvisualstudio.net in my opinion.

Happy Learning,

-Lendog