Write Less, Do More,
But Keep It Simple

Converting web site projects from Visual Studio 2008 Beta 2 to Visual Studio 2008 RTM

bschooley — Wed, 21 Nov 2007 15:44:38 GMT

The good news is that this conversion was a lot less painful than the move from the final beta of .Net 2.0 to it's released version. The only breaking changes I ran into were minor changes in LINQ to SQL. While I was converting web site projects, I imagine since my breaking changes were limited to LINQ to SQL, that these changes would hold true for other projects as well.

First, this is just one scenario, your personal experience may vary.

LINQ to SQL Designer and the DBML File Encoding

This change is self correcting for the most part. If you attempt to open a .dbml file or compile your app before making this change you will get a "Cannot load ..." error. When you click the "Ok" button, the dbml file will automatically be opened with the xml editor. All you need to do is click save, wait for the pause as it regenerates the classes, and then close the file. The error has to do with the utf encoding of the xml file.

Web.config Assembly Reference Change for System.Data.DataSetExtensions

Open your web.config file and find and change the version number in this line from 2.0:

<add assembly="System.Data.DataSetExtensions, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>

to 3.5:

<add assembly="System.Data.DataSetExtensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>

then save and close.

LINQ to SQL Add and Remove Method Name Changes

From here you can attempt to compile to find the remaining changes you need to make. The first ones you'll run into are the Add and Remove methods of the LINQ to SQL Table<> objects. The Add method was changed to InsertOnSubmit and the Remove method was changed to DeleteOnSubmit. While more wordy, the change was made to make them more explicitly describe their behavior.

LINQ to SQL OnValidate Partial Method Change

If you were using the OnValidate partial method, then you'll need to make a small change. But this time you may want to make some alterations to your code logic as well.

To put it simply, the OnValidate now has a ChangeAction parameter. This is a great change as it basically informs the method about the reason for the call. ChangeAction has four values: Insert, Update, Delete and None.

So, find and change all your:

partial void OnValidate()

to:

partial void OnValidate(ChangeAction action)

Depending on what your doing you may want to consider wrapping the contents of your method in a simple:

if (action == ChangeAction.Insert || action == ChangeAction.Update)
{
...
}

You may want to skip that for now and revisit it when you are ready to think through the implications of this change.

Conclusion

My test applications made use of extension methods, nested master pages and a few other 3.5 features, but so far I haven't run into any other breaking changes. If I run across more, I'll update this blog post.

MSDN's 101 LINQ Samples

bschooley — Thu, 25 Oct 2007 16:24:27 GMT

I've been reading about, studying, and using LINQ to SQL for a couple months now and after all this time I somehow never ran across this MSDN web page.

101 LINQ Samples - C# Version

101 LINQ Samples - VB Version (has lots more content and sections on LINQ to SQL, etc)

After just a few minutes of digging through it's samples, I've already learned more than I care to admit. These samples help to show that LINQ is a lot deeper and more expressive than you might think at first glance.

[Update: 10-26]

After some additional searches and aimless browsing on the MSDN site I discovered there are multiple flavors and versions of the "101 LINQ Samples". I've updated the links above to include what I think are the most current pages.

Here are some other links to similar "101 LINQ Samples" pages that I think are out of date but may still have nuggets of value buried in them:

101 LINQ to Entities Samples - Downloadable Zip from the ADO.Net Team (out-of-date)

LINQ Samples from Orcas March CTP - Another Downloadable Zip (out-of-date)

LINQ and language samples for Visual Studio 2008 Beta 2 - Executable samples package from here

ASP.Net : Using a STRUCT to make working with ViewState easier

bschooley — Tue, 09 Oct 2007 15:31:57 GMT

Last week I wrote an article suggesting cleaner ways of using ViewState to store local page variable state. I got some great feedback on that post and this blog is an extension on the topic that I came up with while experimenting with the various techniques brought up.

One of the things I look for in page level coding techniques is simplicity. "Write less, do more", but keep it simple. By simple, I mean easy to write and easy for someone else to read and maintain.

One of the challenges of using ViewState in a simple and efficient way is that it can get wordy. What I mean is with most approaches you end up typing in the variable name three or four times to set up a local variable and an associated property or you set up a local variable and then save and load it during SaveViewState and LoadViewState. All in all, for every variable you end up with multiple lines of declarative code.

After poking it over and over I came up with the idea to use a struct to remove the need for multiple lines of code per variable. Here's the result:

[Serializable()]

protected struct ViewStateStruct

 public int EmployeeID;

 public byte[] Version;

protected ViewStateStruct _vs = new ViewStateStruct();

protected override object SaveViewState()

 { this.ViewState.Add("_vs", _vs); return base.SaveViewState(); }

protected override void LoadViewState(object savedState)

 { base.LoadViewState(savedState); _vs = (ViewStateStruct)ViewState["_vs"]; }

As you can see, if you want to add a variable, you only have to declare it in one place inside the struct. Throughout your code all your ViewState variables are simply referenced by _vs.EmployeeID. If you don't like _vs, then it's easy to change it. Either way, be sure to set a standard name for the struct throughout your project.

In my previous blog on the topic, Tony pointed out an article on CodeProject called Using Attributes for encapsulating ASP.Net Session and ViewState variables. Combining this with the struct idea yields you with the following code in your page.

[Serializable()]

protected struct ViewStateStruct

 public int EmployeeID;

 public byte[] Version;

[PersistField(Location = PersistLocation.ViewState)]

protected ViewStateStruct _vs = new ViewStateStruct();

On the general topic of "write less, do more", there's one other thing I remembered while playing with this and Linq to SQL in the same page. I found when I went to load data from my Linq object to my form fields, I also needed to store the same value in my ViewState variable so that when the page came back, I'd have access to the original value. In C# you can do this:

tbName.Text = _vs.Name = employee.Name;

I seldom remember that but it's pretty useful.

Impressions of Silverlight after attending SilverlightDevCamp Chicago

bschooley — Sun, 30 Sep 2007 13:15:24 GMT

I just spent Friday night and Saturday at the SilverlightDevCamp in Chicago. I'm glad I went as it gave me a chance to think for a couple days about Silverlight and other related topics. I knew a bit about Silverlight before going as I've been following it for a while now, but I admit I haven't written anything in it yet. Overall, the sessions were pretty good given the nature of this type of event is to have everything presented by the people attending it rather than bring someone in to present on a topic and have everyone else listen.

So what are my impressions of Silverlight now?

Well, it really reminds me of the early days of java applets in MCSA Mosaic. When everyone was rushing to make news tickers and couldn't think of much else to do with it. (And yes, I was there and actually wrote one of the first ticker applets used in production on the web.) Obviously it took some time for people to get past that stage and it took time for the technology to mature enough to allow more interesting things to be done.

I have no doubt that Silverlight will be a big success and I personally think it will be bigger than most people realize. The folks at Microsoft that are behind it's development undoubtedly realize it too but so far they aren't selling it as the "next significant technology move for web delivered applications" that it has the potential to become.

Why do I think that?

1. It leverages the .Net framework as the development platform, and let's face it, there are millions of .Net developers who will soon be able to create rich applications that delivered and live in the browser. (Of course I'm speaking of Silverlight 1.1, 1.0 is a technology teaser destined to be replaced by the real Silverlight.)

2. It's really going to be cross platform (Windows, Mac AND Linux). It is worth noting that this is the first time Microsoft has ever blessed and supported a development effort for Linux.

3. It does away with the compatibility problems we currently face with developing rich applications in html and javascript that need to support multiple browsers on multiple operating systems.

4. Like it or not... accept it or not... richer applications are going to be future. By rich applications I'm speaking more of the improved user experience they provide and not the pretty bells and whistles. It may not be as clearly delineated as the move from green screens to windows style interfaces, but there will be a clear difference html driven websites of today and the Silverlight driven websites of tomorrow.

When will this happen?

It's going to take time for this to happen and it could implode on itself along the way. First we'll see early adopters scrambling to make something of it, then slowly it will move into the main stream. It's hard to tell how fast this will happen, but my guess is that we're looking at one to two years before it really gets started and another year or two before users start asking for it. During this period, several hurdles must be overcome and competing technologies such as Adobe's Flex/Air could speed or slow the process.

Well, that's my take on it. I could be completely wrong about everything I've written here so far, but at least on this next note, I know I'm right... Silverlight is definitely something worth keeping an eye on and if you're a .Net developer it will be worth your time to learn more about it. I'll even go one step further and say if you are a .Net developer you should plan to learn to how to develop with it.

For now, keep moving forward with what you're doing, but prepare yourself for the changes ahead.

LINQ to SQL : Handling disconnected CRUD operations in ASP.Net

bschooley — Sat, 29 Sep 2007 21:37:13 GMT

Most LINQ to SQL examples you find on the net tend to be written in a way that assumes a connected environment. I've found some blogs and posts that also talk about disconnected operations, but many of those are coming from the perspective of multiple tiers where the entity objects are being passed between tiers.

For this example, I've got a page that handles simple CRUD operations for a single employee record. It takes a query string parameter of "id". When it's not passed or "0" is passed, then it assumes you are going to be adding a new employee record, otherwise it loads the employee and allows you to edit it.

Note: I'm using module (page) level variables that are read from and stored in ViewState by overridden SaveViewState and LoadViewState. See my blog post on the subject.

Here's the OnLoad method...

protected override void OnLoad(EventArgs e)

 if (!IsPostBack)

 _EmployeeID = Convert.ToInt32(Request.QueryString["id"] ?? "0");

 if (_EmployeeID != 0)

 DB.NW.DataContext dc = new DB.NW.DataContext();

 DB.NW.Employee employee = dc.Employees.Single(em => em.EmployeeID == _EmployeeID);

 _Version = employee.Version;

 tb_FirstName.Text = employee.FirstName;

 tb_LastName.Text = employee.LastName;

 tb_HomePhone.Text = employee.HomePhone;

 base.OnLoad(e);

I'm going to assume you seen the reading of a single record from a LINQ to SQL DataContext, if not Scott Guthrie has a good introduction to LINQ to SQL you should read first. I'm also using the null coalescing operator, if that's new to you then again, Scott covered that too.

Notice here that I'm storing two values to local variables (ie ViewState). The _EmployeeID and the _Version. The version field is a row TimeStamp field I've added to the Employee table to facilitate concurrency checking on updates. I'll talk more about this later in this post.

Now for the good stuff. Here's the Save method...

protected void Save(object source, EventArgs e)

 DB.NW.DataContext dc = new DB.NW.DataContext();

 DB.NW.Employee employee = new DB.NW.Employee();

 if (_EmployeeID == 0)

 employee.FirstName = tb_FirstName.Text;

 employee.LastName = tb_LastName.Text;

 employee.HomePhone = tb_HomePhone.Text;

 dc.Employees.Add(employee);

 else

 employee.EmployeeID = _EmployeeID;

 employee.Version = _Version;

 dc.Employees.Attach(employee);

 employee.FirstName = tb_FirstName.Text;

 employee.LastName = tb_LastName.Text;

 employee.HomePhone = tb_HomePhone.Text;

try

 dc.SubmitChanges();

 Response.Redirect("~/Employees.aspx");

 catch (Exception ex)

 lbl_Message.Text = ex.Message;

Let's break it down.

When adding a new employee record.

Start by creating a DataContext and a new Employee object. Then set the properties based on the form control values and "Add" the employee object to the DataContext's Employees table. Finish with a SubmitChanges().

When updating things get a bit more interesting.

Start by setting the id and version properties of the new employee object and then "Attach" the it to the DataContext's Employees table. After it is attached, move the form control values to the employee object and finish by calling SubmitChanges().

It is important to understand why this sequence of steps is required for an update. The attach step is the key and it relates to how the DataContext tracks changes to objects. The "Attach" tells the DataContext that we have this employee object with an id of _EmployeeID and a row version timestamp of _Version and we want you to know about it and track any further changes so you can save them. When calling SubmitChanges(), the DataContext will create it's update statement and only include fields that changed after the object was attached.

Variations on the Update

While the code above is a complete workable approach, there are some assumptions and pre-requisites that led to it. First, the table has a timestamp field to track the row version for concurrency checking. If your table doesn't have one, in most cases I'd suggest adding it. If that's not possible then you have a few options, all of which involve more work on your part.

The easiest option is to turn off concurrency checking by changing the "update check" attribute for each field and setting it to "never". By default, LINQ to SQL sets the attribute to "always". This will allow the above code above to continue to work (just remove the lines dealing with the Version field). But removing concurrency checking isn't a good idea unless you intend to handle it yourself by adding your own code for it to the update process above.

What you shouldn't do is simply re-retrieve the employee record and change its properties. If you are handling the currency checking on your own via a property by property compare or a last updated date time value, you may think you are covered. The problem is that you are either trying to ignore concurrency checking or you are doing your own concurrency checking while still allowing LINQ to SQL to do it's concurrency checks as well so you may get a LINQ to SQL concurrency error if two users try to update a record a the same time, even if you are doing some amount of your own checking. It the end you either need to use LINQ to SQL's concurrency process or to turn it off.

Here's a bit more food for thought on this subject. Below are approaches to updates and the SQL statements generated by LINQ to SQL.

First, the code from above that makes use of a Version field and LINQ to SQL's concurrency checking...

DB.NW.Employee employee = new DB.NW.Employee();

employee.EmployeeID = _EmployeeID;

employee.Version = _Version;

dc.Employees.Attach(employee);

employee.FirstName = tb_FirstName.Text;

employee.LastName = tb_LastName.Text;

employee.HomePhone = tb_HomePhone.Text;

dc.SubmitChanges();

...generates...

UPDATE [dbo].[Employees]

SET [LastName] = @p2, [FirstName] = @p3, [HomePhone] = @p4

WHERE ([EmployeeID] = @p0) AND ([Version] = @p1)

Turning off update checks on your fields and removing the Version field leaves you vulnerable to concurrency issues, but here's the code...

DB.NW.Employee employee = new DB.NW.Employee();

employee.EmployeeID = _EmployeeID;

dc.Employees.Attach(employee);

employee.FirstName = tb_FirstName.Text;

employee.LastName = tb_LastName.Text;

employee.HomePhone = tb_HomePhone.Text;

dc.SubmitChanges();

...generates...

UPDATE [dbo].[Employees]

SET [LastName] = @p1, [FirstName] = @p2, [HomePhone] = @p3

WHERE [EmployeeID] = @p0

And last, if you leave the Update Check on and re-retrieve the employee record the code ...

employee = dc.Employees.Single(em => em.EmployeeID == _EmployeeID);

employee.FirstName = tb_FirstName.Text;

employee.LastName = tb_LastName.Text;

employee.HomePhone = tb_HomePhone.Text;

dc.SubmitChanges();

...generates...

UPDATE [dbo].[Employees]

SET [HomePhone] = @p15

WHERE ([EmployeeID] = @p0) AND ([LastName] = @p1) AND ([FirstName] = @p2)

AND ([Title] = @p3) AND ([TitleOfCourtesy] = @p4) AND ([BirthDate] = @p5)

AND ([HireDate] = @p6) AND ([Address] = @p7) AND ([City] = @p8)

AND ([Region] IS NULL) AND ([PostalCode] = @p9) AND ([Country] = @p10)

AND ([HomePhone] = @p11) AND ([Extension] = @p12) AND ([ReportsTo] = @p13)

AND ([PhotoPath] = @p14)

As you can see in the last of the three update statements, LINQ to SQL is sending every field as part of the update statement's where clause. I'll also point out here that in this case, LINQ to SQL does know that the FirstName and LastName fields were not changed to new values and therefore didn't include those in the update.

A Note on Change Tracking

This is a more advanced and situational concept, but one of the interesting possibilities that LINQ to SQL enables is the ability to build change tracking into the SubmitChanges() process. The basic idea is that any time you make changes to the database, you first go through the list of changes being made and record them in a generic change log table. I'll be writing about this idea in a later post, but for now, I'll throw out a warning that may effect how you handle updates.

When using the model I suggest at the beginning of this post, the DataContext doesn't know the original values of the three fields (FirstName, LastName and HomePhone) that are being set. As far as the DataContext is aware, the original values are null so, even if nothing is really changing, the fields will be added to the change set. This means when you go through the change set during SubmitChanges() the original values will be empty. So, if you want to really know, at a field level what is truly changing, you'll need to take a different approach that what is shown above.

Here I've stored the original values for all fields that can be updated and I set the employee object to those values before attaching it to the Employees table.

DB.NW.Employee employee = new DB.NW.Employee();

employee.EmployeeID = _EmployeeID;

employee.Version = _Version;

employee.FirstName = _FirstName;

employee.LastName = _LastName;

employee.HomePhone = _HomePhone;

dc.Employees.Attach(employee);

employee.FirstName = tb_FirstName.Text;

employee.LastName = tb_LastName.Text;

employee.HomePhone = tb_HomePhone.Text;

dc.SubmitChanges();

...generates...

UPDATE [dbo].[Employees]

SET [HomePhone] = @p2

WHERE ([EmployeeID] = @p0) AND ([Version] = @p1)

In this case, LINQ to SQL knows the original values for the properties and as in the third example I gave earlier it generates the update set statement with the HomePhone, which was the only field that changed. During the SubmitChanges, if you look into the ChangeSet and retrieve the list of changed properties, you'll find that only the HomePhone is given and it has the original and new values. This will enable you to record the changes in your generic change log table.

So, in order to do both change tracking at the field level and concurrency checking in a disconnected environment such as ASP.Net, you need to be able to create your employee object and set all the properties that you may be changing to their original values before you attach and then update those properties.

I'll be writing a post later that goes into more detail and presents the pros and cons on a few different approaches to tracking original values for objects that you will be updating.

ASP.Net : Clean up your use of ViewState

bschooley — Sat, 29 Sep 2007 16:37:00 GMT

Note: After reading this article, be sure to check out the followup article, "Using a STRUCT to make working with ViewState easier", where I take the ideas here and go one step further.

This is a big pet peeve of mine, so bear with me. I'll keep it short and to the point.

I'm a stickler for organized readable code and the use of ViewState is one of those things that can and should be standardized.

Typically you see developers directly access ViewState in the middle of doing other things. When you use this approach it means that when someone else reads through the code to maintain or enhance it, they have to look through all the code to see what is being placed in ViewState in order to know what they have to work with.

Let's jump right to my suggested approach and look at the code...

private int _EmployeeID = 0;

private byte[] _Version;

protected override object SaveViewState()

 this.ViewState.Add("_EmployeeID", _EmployeeID);

 this.ViewState.Add("_Version", _Version);

 return base.SaveViewState();

protected override void LoadViewState(object savedState)

 base.LoadViewState(savedState);

 _EmployeeID = (int)ViewState["_EmployeeID"];

 _Version = (Byte[])ViewState["_Version"];

Place the private variable declarations at the top of your module. You can follow immediately with the save and load overrides or move them elsewhere. I like having the save and load at the bottom of my code because I like to have my OnLoad be the first method in my code.

Why does it matter?

1. As I mentioned above it makes it easier for someone else to read your code and know what module level variables are being used. (Be sure to use a module level variable naming convention such as the _ prefix as well.)

2. ViewState is read once and written to once per variable rather than reading (and casting) it every time it's used in your code.

3. Because it makes you look like a professional. Seriously, take time to write clean organized code that follow standards and best practice approaches even when the module or page is very small.

[Edited 10/2/2007]

Alternate Approaches Suggested in the Comments Below

I like feedback and this post has some great feedback. My favorite, which honestly blew me away, is the attribute technique suggested by Tony. The full details can be found in the Code Project article, Using Attributes for encapsulating ASP.Net Session and ViewState variables. Declaring a variable on a page that is to be stored in ViewState is as simple as:

[PersistField(Location = PersistLocation.ViewState)]

protected int _EmployeeID;

To enable this you need to override the page class and create a custom attribute. If you already override the page class in your project then moving to this technique is almost a no-brainer.

What's so elegant about this besides the reduced about of code required, is that what you're doing is completely obvious since the variable is declared at the same place where you flag it for persistence via ViewState.

Another Approach

Michael Teper suggested the property approach.

private int _EmployeeId

 get { return (int) ViewState["_EmployeeId"]; }

 set { ViewState["_EmployeeId"] = value; }

If the attribute approach doesn't work for you, then this is probably the best way to handle ViewState, I've used it myself, but for some reason I've never changed my default coding approach to it. While this potentially reads values from ViewState multiple times, it doesn't do any reads if you don't use the property.

LINQ to SQL : Start with a good foundation by defining a custom DataContext

bschooley — Fri, 28 Sep 2007 05:43:00 GMT

This is my first post in a what will become a series of posts on LINQ to SQL. As the title of my blog suggests, I'm going to be "thinking out loud" as I write these and I'm hoping for feedback from others on the pro's and con's of the approaches I'm suggesting. That said, the point of this series of posts will be to define a loose set of best practices around developing with LINQ to SQL in an ASP.Net web environment. The first couple posts will be pretty simplistic but I wanted to get these in place first so I can refer to the concepts later without having to go into detail.

On with the topic at hand...

When starting a new project with LINQ to SQL, it's a good idea to wrap the DataContext with your own class that inherits from the DataContext generated by the designer (or SQLMetal).

Before we do that though, let's take a small step back and talk about namespaces. In the designer, if you click on design surface background, you'll select the DataContext. In the properties window there will be two entries related to namespaces. One is the Context Namespace and the other is the Entity Namespace. Typically you'd put both the generated DataContext and the entity classes within the same namespace, but since we're going to be creating our own DataContext that inherits from the one that is generated for us, I'd suggest that we set these up with different namespaces.

I like to have my data layer to have its own namespace and as such I tend to go with a DB.such_and_such namespace where such_and_such is the name of our database or other logical context name. I'll be using the northwind database for this series of posts, so the logical namespace name is DB.NW. This is what we should put in the Entity Namespace property, but for the Context Namespace, we should set the value to DB.NW.Base to leave room for our custom version in the DB.NW namespace. With our DataContext's name set as simply DataContext as well, we'll get the following generated for us by the designer...

namespace DB.NW.Base
{
    ...
    public partial class DataContext : System.Data.Linq.DataContext
    {
    ...
    }

}
namespace DB.NW
{
    ...
    [Table...]
    public partial class table_name... etc.
}

Next we need to create a new class file in app_code. In this case I'll keep the name the same as the namespace it contains and go with DB.NW.cs.

using System;
using System.Data.Linq;
using System.Data.Linq.Mapping;
using System.Linq;
using System.Runtime.Serialization;
using System.Reflection;

namespace DB.NW
{
    public class DataContext : DB.NW.Base.DataContext
    {
    }
}

Now, it may seem silly at this point to go through all this but doing this now, even with no custom or overridden methods, will save us from having to change our code later that when we need to override methods such as SubmitChanges()..

Write Less, Do More, But Keep It Simple

Converting web site projects from Visual Studio 2008 Beta 2 to Visual Studio 2008 RTM

MSDN's 101 LINQ Samples

101 LINQ Samples - C# Version

101 LINQ Samples - VB Version (has lots more content and sections on LINQ to SQL, etc)

ASP.Net : Using a STRUCT to make working with ViewState easier

Impressions of Silverlight after attending SilverlightDevCamp Chicago

LINQ to SQL : Handling disconnected CRUD operations in ASP.Net

ASP.Net : Clean up your use of ViewState

LINQ to SQL : Start with a good foundation by defining a custom DataContext

Write Less, Do More,
But Keep It Simple