Fortunately It seems I just found the solution: After uninstalling the “Microsoft Visual Studio Web authoring Component”, the problem seems have to have disappeared. I’m not even sure what this component does, but it seems to be a relict from Visual Studio 2005 and so far I have not noticed any missing features since I uninstalled it.

Since I wrote the first part of the article, Steve Sanderson adopted my idea of automatic client-side validation and baked a similar feature right into the latest version of xVal.

One important thing is still missing though: What do you do when validation depends on server-side resources but also involves several different form fields? For example, let’s assume you were implementing a form for your website users to update their contact information.

Figure 1 – Example update form

The form is very similar to the signup form from the last part of this article. However this time instead of adding new data to the database, the user needs to update his e-mail address. Validation still has to check that the e-mail address entered does not already exist yet. However, this time it should ignore the current user’s e-mail address.

For example, if the current user’s e-mail address is adrian@lobstersoft.com, then we still want to accept this as valid input. But if he enters “john@doe.com” and that e-mail address is already taken, we want client-side validation to fail.

And all of this should of course work automatically on both the server and client side simply by providing a server-side validation rule and attaching it the Viewmodel:

Listing 1 – ViewModel with client/server side enabled entity validation attribute

    [EmailUnique]
    public class UserModel
    {
        public int ID{ get; set;}

        [Required(ErrorMessage = "E-mail address is missing.")]
        [RegularExpression(EmailRegEx, ErrorMessage = "Invalid e-mail address.")]
        [EmailUnique]
        public string Email { get; set; }

        public class EmailUniqueAttribute : RemoteEntityValidator
        {
            public EmailUniqueAttribute()
                : base(new string[] { "Email", "ID" }, typeof(User))
            {
                ErrorMessage = "Someone else has already signed up with this e-mail address.";
            }

            protected override bool EntityValid(object value)
            {
                User entity = (User)value;
	      //make sure there is no user with a different ID but same e-mail address
                return !new FakeUsersRepository().LoadAll().Any(u => u.ID != entity.ID && u.Email == entity.Email);
            }
        }

	// Other UserModel properties and validation attributes...
}

Behind the scenes

Validation of the e-mail input on this form depends on two variables: The user’s e-mail address and his user ID.

Therefore we need to:

1. Store the user id as a hidden form input field
2. Provide a client-side Javascript function that creates a remote validation rule that submits all relevant form input fields for the particular validation rule to the server.
3. Provide a server-side action method that triggers the validation attribute’s IsValid method and returns the result to the client-side remote validator.

The approach is quite similar to remote property validation, except that multiple form input fields have to be provided to the server, but there are also a few other other minor differences. For example the client-side remote validation rules must also be re-validate when one of the other form input elements that validation depends on is changed.

But the good news is that all of this can be still solved in a generic way so that you can get away just by coding your server-side data annotation validation attributes – Very similar to the technique shown in the first part of this article.

Using the RemoteEntityValidator

For using the code provided with this article in your own project, proceed as follows:

1. Add Xval, jquery.validate, DataAnnotationModelBinder and the code provided in this article’s demo project to your project as shown in the first part of this article.
2. Next, whenever you need to write a validation attribute that depends on multiple properties of your view model, derive your validation attribute from RemoteEntityValidator as shown in Listing 1.

These are the differences you have to mind in comparison to the RemotePropertyValidator from the first part of the article:

• The RemoteEntityValidator’s constructor takes one more variable than the RemotePropertyValidator: A string array of all property names in the ViewModel which are relevant for running the validation rule. I guess this could also be done in a more type-safe way by using Linq expressions, but I chose strings for the sake of a simpler syntax, especially when handling many different form fields.

• Note that even though the RemoteEntityValidator depends on several model properties, you must not apply it to all relevant properties in your model. Just apply it to the ViewModel entity and the property that corresponds to the html input element where you want the client-side validation error to appear. However, you do have to apply it both to the ViewModel property AND to the ViewModel class. The property-level attribute is needed for the triggering client side validation when the input element is changed, and the entity-level attribute is needed for server side validation to work.

• Your html form needs to have an ID attribute. It could be done without, but in my project this led to some problems with client-side validation when the form was reloaded via ajax. That’s why I changed the client-side code for retrieving form input values to something more stable since posting the first part of this article.

Download the demo project

Conclusion

You have learned how to implement client- and server-side validation in a completely generic, model-oriented way. This part of the article completed the technique shown before with validation attributes that depend on several model properties.

In addition, there are some validation rules which cannot be checked completely on the client side, for example because the validation depends on information stored in the server database. For those rules you need to implement remote client-side form validation.

The xVal framework is great for automatic generation of client-side validation code for some of your server-side validation rules, but it does not support remote client-side validation.

This article shows a fully generic way to implement remote client-side form validation so that

• Validation rules remain solely in your ASP.NET MVC model
• You write each validation rule just once, and only in easily testable C# code. There is no JavaScript or other client-side counterpart .
• There is no need to branch or otherwise modify xVal or jquery.validate
• All you have to do for each new remote form validation rule is to derive from the base class shown in this article.

I’ll describe how to implement this in detail. I’ve also uploaded a demo project showing how this works in action.

A brief example

Let’s assume you are implementing a website signup form. For the sake of simplicity, lets limit the form to asking for an e-mail address and a password.

Figure 1 – Example signup form

You want to implement the signup form with both client and server side validation. For the e-mail field, let’s enforce the following validation rules:

1. Email address is not missing
2. Email address looks valid
3. There is no other user with the same e-mail address in your database.

Rules 1 and 2 can easily be checked on the client side. However, rule 3 can only be done with remote validation: Your client-side validation script needs to connect to your web server and ask if the e-mail address is already taken.

In our example, the only user already in the databse shall be adrian@lobstersoft.com. As soon as someone enters this e-mail address in the form and hits tab, return, or the Create button, an error message should appear before the form has even been posted:

Figure 2 – Error messages should appear before the form has even been posted

Listing 1 shows the entire validation logic necessary for both client and server side validation:

Listing 1 – Signup form client- and server-side validation rules

using System.ComponentModel.DataAnnotations;

namespace RemoteValidation.Models
{
    public class User
    {
        [Required(ErrorMessage = "E-mail address is missing.")]
        [RegularExpression(EmailRegEx, ErrorMessage = "Invalid e-mail address.")]
        [IsNew(ErrorMessage = "Someone has already signed up with this e-mail address.")]
        public string Email { get; set; }

        [Required(ErrorMessage = "Password is missing.")]
        public string Password { get; set; }

        public class IsNewAttribute : RemotePropertyValidator
        {
            protected override bool PropertyValid(object value)
            {
                return (string)value != "adrian@lobstersoft.com";
            }
        }

        private const string EmailRegEx = @"^(([^<>()[\]\\.,;:\s@\""]+"
                                  + @"(\.[^<>()[\]\\.,;:\s@\""]+)*)|(\"".+\""))@"
                                  + @"((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}"
                                  + @"\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+"
                                  + @"[a-zA-Z]{2,}))$";
    }
}

The SignUp action methods should also be easy to implement since the controller does not need to know anything about our validation rules.

Listing 2 – Signup form action methods

         //
        // GET: /Users/SignUp
        public ActionResult SignUp()
        {
            return View(new User());
        }

        //
        // POST: /Users/SignUp
        [AcceptVerbs(HttpVerbs.Post)]
        public ActionResult SignUp(User model)
        {
            if (!ModelState.IsValid)
            {
                return View(model);
            }

            //Add User to database and start spamming daemon here

            return RedirectToAction("SignUpComplete");
        }

Lastly, here’s how the view above is implemented.

Listing 3 – Signup form view implementation

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage<RemoteValidation.Models.User>" %>

<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent" runat="server">
    SignUp
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">
    <h2>
        SignUp</h2>
    <%= Html.ValidationSummary("SignUp was unsuccessful. Please correct the errors and try again.") %>
    <% using (Html.BeginForm())
       {%>
    <fieldset>
        <legend>Fields</legend>
        <p>
            <label for="Email">
                Enter your e-mail address:</label>
            <%= Html.TextBox("Email")%>
            <%= Html.ValidationMessage("Email", "*")%>
        </p>
        <p>
            <label for="Password">
                Enter a password:</label>
            <%= Html.Password("Password")%>
            <%= Html.ValidationMessage("Password", "*")%>
        </p>
        <p>
            Hint: To see that remote validation works, try signing up as "adrian@lobstersoft.com".
        </p>
        <p>
            <input type="submit" value="Create" />
        </p>
    </fieldset>
    <% } %>

    <%= Html.ClientSideValidation<RemoteValidation.Models.User>()%>
</asp:Content>

Note that the View does not contain any JavaScript or other means to specify client-side validation rules. Everything is done transparently and automatically behind the scenes.

Prerequisites

In order for this to work, you need to set up a few things first:

1. Data Annotation validation attributes for server-side validation. IMO this is the best way to handle server-side validation anyway, even if you are not using client-side validation at all.

   Brad Wilson has written a great blog article on how to use DataAnnotations in ASP.NET MVC.

   Note that there is a bug in DataAnnotationModelBinder which might lead to NullReferenceExceptions when using custom ViewModels. This does not become apparent in our demo project, but if you should encounter this problem, you can find a fix in this StackOverflow posting.

2. Download and reference jquery.validate in your Master Page.
3. Download and reference xVal version 0.8 or later in your project. xVal is a great framework for easy implementation of client-side validation in ASP.NET MVC. It transforms standard server-side validation rules into client-side validation rules recognized by jquery.validate.

   Steve Sanderson describes how to set it up and use in this blog article.

Once you get this far, you can implement rules 1 and 2 from our example. You could also implement rule 3, although you’d have to derive it from System.ComponentModel.DataAnnotations.ValidationAttribute, so there would’t be any client-side validation for that.

Implementing generic client-side Remote Validation

While rules 1 and 2 are automagically enforced by xVal on both the client and server side, rule 3 is only checked when the user posts the form. That’s because xVal does not know what to do with our custom rule. It just looks for standard validation rules like Required, StringLength or RegularExpression and ignores everything else.

Enforcing rule 3 on the client side as well without incurring any additional effort is where the technique I would like to present comes into play.

The first step is not to derive your custom validation rule from ValidationAttribute, but from the RemotePropertyValidator class I implemented. This is already depicted in Listing 1 above.

RemotePropertyValidator is in turn derived from ValidationAttribute, but it also implements xVal’s ICustomRule interface. This allows it to specify a JavaScript function that should be executed in order to check if the given property is valid on the client side.

RemotePropertyValidator tells xVal to execute the JavaScript function “RemotePropertyValidation”. The parameters for this function should be the type of your derived custom validator and the Error message you specified:

Listing 4 – RemotePropertyValidation class

   public abstract class RemotePropertyValidator : ValidationAttribute, ICustomRule
    {
        public CustomRule ToCustomRule()
        {
            return new CustomRule(
                "RemotePropertyValidation", // JavaScript function name
                new
                    {
                        validator = ToString(),
                        errorMessage = base.ErrorMessage,
                    }, // Params for JavaScript function

                base.ErrorMessage
                );
        }
    }

You might be wondering why I am checking for empty strings / null in Listing 4. That’s because of differences between how xVal / jquery.validate work on the client side and how the DataAnnotationsModelRunner is implemented on the server side: While it is possible to implicitly implement a Required validator by deriving from ValidationAttribute on the server side, it is not possible to do this with ICustomRule descendents on the client. So I am checking for empty strings / null to avoid inconsistent behaviour.

The ClientSideRegEx property can be set to a regular expression that will be executed on the client before the remote validation is done. You can use it to avoid unnecessary calls to your RemoteValidation controller.

Now, when the user starts typing something in the e-mail field, the browser will execute the JavaScript function “RemotePropertyValidation”. Note that this function will receive your derived server-side validator’s object type and your validator’s error message as parameters.

Next, we need to implement a generic RemotePropertyValidation function. In this function we can create a “remote” validation rule as supported by jquery.validate and attach it to the Email e-mail input field’s rules collection:

Listing 5 – Generic client-side remote validation function

function RemotePropertyValidation(value, element, params) {
    var wrappedElement = $(element);
    if (wrappedElement.rules()["remote"] === undefined) {
        //add optional regEx validator to minimize ajax requests
        if (params.regEx !== null && wrappedElement.rules()["xVal_regex"] === undefined) {
            wrappedElement.rules("add", {
                xVal_regex: [params.regEx],
                messages: {
                    xVal_regex: params.errorMessage
                }
            });
        }
        var remoteRule =
        //add a new remote validation rule
        wrappedElement.rules("add", {
            remote: {
                url: "/RemoteValidation/Property",
                data: {
                    value: new CreateInputValueAccessor(wrappedElement.attr("name")),
                    validator: params.validator
                }
            },
            messages: {
                remote: params.errorMessage
            }
        });

        //validate element again to trigger the new rule(s)
        $("form").validate().element(wrappedElement);
    }
    return true;
}

function CreateInputValueAccessor(inputName) {
    return function() {
        return $("[name=" + inputName + "]").val();
    };
}

The RemotePropertyValidation () function should be referenced in your Master page. Now the first time a user enters something in the Email field , jquery.validate will first validate it using the Required and the Regex rule. If both rules are satisfied, it will check if the e-mail address is already taken with the validation rule that RemotePropertyValidation() inserted on the fly. This will fetch the following URL and parse the JSON reply as validation result.:

http:///RemoteValidation/Property?value=&validator=RemoteValidtion.Models.User.IsNew

Now we just need to implement a RemoteValidation that construct an appropriate validator object (note that this is provided in “validator” request parameter), let it validate the user input and return the validation result as JSON:

Listing 6 – RemoteValidation controller

using System;
using System.Reflection;
using System.Web.Mvc;
using RemoteValidation.Models;

namespace RemoteValidation.Controllers
{
    public class RemoteValidationController : Controller
    {
        //
        // GET: /RemoteValidation/Property
        public JsonResult Property()
        {
            Type validatorType = Type.GetType(Request["validator"], true);
            var validator = (RemotePropertyValidator) Activator.CreateInstance(validatorType);
            return Json(validator.IsValid(Request["value"]));
        }
    }
}

And that’s it! Now that you have the JavaScript RemotePropertyValidation function and the remote validation controller in place, all you need to do for new custom validation rules is to derive them from RemotePropertyValidator. This ensures that your validation rules are are automatically enforced on both the server and the client.

For example, all you’d need to implement for server AND remote client-side validation of password strength is this:

Listing 7 – Complete implementation of an additional client- and server-side Validator

 public class IsSafePasswordAttribute : RemotePropertyValidator
        {

            public IsSafePasswordAttribute()
            {
                //perform some simple password strength check with a regular expression
                //on the client side first
                ClientSideRegEx = ".{8,20}";
            }

            protected override bool PropertyValid(object value)
            {
                //Insert more elaborate server-side / remote client side password checking
                // logic and return result here...
            }
        }

Caveats

There are a few things you should keep in mind when using this technique:

• You can’t implicitly implement a Required validator using this technique, so if a property is not optional, you must always decorate it with a Required validator apart from of your own RemotePropertyValidator descendant. It wouldn’t really make sense to implement a Required validator this way anyway. Please see the Implementation section above if you are interested in the reason for this.
• You can only apply one remote validation rule per form field. This is a limitation of jquery.validate, and it makes sense not to have more than one remote validation rule anyway since you want to minimize the amount of server postbacks as much as possible. If you need to remotely check two different rules on the same property, you can always write a new rule which incorporates both checks, so the only problem is finding an error message that fits both validation rules.
• This approach only works for Validation Attributes applied to properties, not to entire business entities. I’ll discuss a similar approach for validating entire business entities in the second part of this article.

Download the finished demo project

Summary

Now you know how to implement remote client-side validation without writing any custom JavaScript code. I discussed how to implement all validation rules, even those that can only be checked on the server, on both the client AND server side in C# code only. I showed how you can do this without any additional effort when implementing new rules.

The only real limitation is that the business rule can check only a single property, not an entire business entity. Stay tuned for the second part of this article, where I’ll discuss how to circumvent this limitation in a similarly easy way.

Edit: The second part of this article has already been posted here.

Tools like Resharper can notify you of syntax errors within your views, but you can still build the project and not get a single error. Instead, your application will crash when trying to evaluate the buggy view.

Fortunately you can easily make Visual Studio compile your views along with the rest of your code. The only downside is that your project will build a bit slower, but if this bothers you during development you can also enable this feature on a per configuration basis. For example you may want to compile your views in Release mode, but not in your Debug configuration , so you have the extra safety of compile-time view checking before releasing a new version, but you still get lightning-fast compilation times while developing.

Please proceed as follows to turn on compile time view compilation:

1. Open your .csproject or .vbproject file in a text editor of your choice. It’s just a simple xml file, which is why any editor will do fine.
2. Locate the <PropertyGroup> element that belongs to the configuration you would like to alter.
3. Within this PropertyGroup, add an additional element with “true” as its text value.

For example, this will turn on view compilation in my project’s Release configuration:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">

<MvcBuildViews>true</MvcBuildViews>

...

That’s it! The next time one of your views has compile-time errors, these will be reported when building your application.

One last thing: You need to repeat this procedure for all configurations you might create in the future if you want your views to be checked in those configurations as well. Even if you tell Visual Studio to copy settings from an existing configuration where this tag is already set to true, the MvcBuildViews tag is not copied by Visual Studio.

Edit: As some readers pointed out, your project’s compilation time will increase after turning on view compilation. For this reason, I have recently switched it off for the debug configuration of my current project. However, compile-time view compilation is still tremendously useful before releasing a new version. Or perhaps even before submitting a new revision to your source control server. It can catch a lot of different errors this way, especially if you are using the new ASP.NET MVC strongly typed Html helpers.

One thing that still puzzled me after reading and trying to follow the chapter was how to create complex custom ViewModels (as opposed to putting all data in the ViewData dictionary or using vanilla Linq to SQL entities). Scott mentions on page 107 of the book that you “might have the action method update a ViewModel object with the form-posted data, and then use the ViewModel instance to map or retrieve an actual domain model object”, but there is no actual example of how this would look in source code.

For example, let’s assume you have an edit action method with the following view:

So your edit form displays data coming from a Linq entity representing a customer (FirstName, LastName, Email, Country, AccountType), but you also need SelectLists to populate the Country and AccountType DropDownLists.

The simple, but untyped approach: the ViewData dictionary

The simplest approach is to use the Customer Linq entity as ViewModel and to put the two SelectLists in the ViewData dictionary. This works fine, but I dislike the fact that there is no type-safety for the two SelectLists. Instead you have to use a type cast from object to SelectList:

<label for="CountryCode">Country</label><br />
<%= Html.DropDownList("CountryCode",ViewData["Countries"] as SelectList)%>

<%= Html.ValidationMessage("CountryCode", "*")%>

The fully typed approach: Custom ViewModels

So you want fully typed model data, but the linq entity does not hold all the data you need to render the view. Since you don’t want to clutter my Customer Linq to SQL entity with two properties that return the two SelectLists, the only alternative to get a fully typed view is to use a custom ViewModel:

public class CustomersFormViewModel
{
public SelectList AccountTypes { get; set; }
public SelectList Countries { get; set; }
public Customer Customer { get; set; }
}

Note that the ViewModel is not a mere Linq entity anymore. Instead, it contains the one Customer Linq entity instance, plus the two SelectLists for my DropDownLists.

Now you can implement your view without using any typecasts:

<p>

<label for="Customer.FirstName">

FirstName:</label><br />

<%= Html.TextBox("Customer.FirstName")%>

<%= Html.ValidationMessage("Customer.FirstName", "*")%>

</p>

<p>

<label for="Customer.LastName">

LastName:</label><br />

<%= Html.TextBox("Customer.LastName")%>

<%= Html.ValidationMessage("Customer.LastName", "*")%>

</p>

<p>

<label for="Customer.Email">

Email:</label><br />

<%= Html.TextBox("Customer.Email")%>

<%= Html.ValidationMessage("Customer.Email", "*")%>

</p>

<p>

<label for="Customer.CountryCode">

Country</label><br />

<%= Html.DropDownList("Customer.CountryCode",Model.Countries)%>

<%= Html.ValidationMessage("Customer.CountryCode", "*")%>

</p>

<p>

<label for="Customer.AccountType">

AccountType:</label><br />

<%= Html.DropDownList("Customer.AccountType",Model.AccountTypes)%>

<%= Html.ValidationMessage("Customer.AccountType", "*")%>

</p>

I was wondering if the MVC framework can automatically map the form values and reconstruct a CustomersFormViewModel. In other words, can I simply implement a strongly typed POST edit action method and receive a fully populated ViewModel as a parameter like this:

//POST: /CustomersController/Edit

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Edit(CustomersFormViewModel model)
{
//validate data, save customer, handle validation errors...
}

The answer is yes! The MVC framework even maps object hierarchies of any depth as ViewModels.

How not to do it

This is all really easy, but still there were few things that threw me off at the beginning.

The ViewModelBinder only maps properties, not public fields. A ViewModel like this cannot be mapped:

public class CustomersFormViewModel
{
public electList AccountTypes;
public SelectList Countries;
public Customer Customer;
}

The names of your POSTed form values must match the object hiearchy you want them to be mapped to. Something like this will not work:

<p></p></p></p></p></p></p></p></p></p></p>

<label for="FirstName">

FirstName:</label><br />

<%= Html.TextBox("FirstName",Model,Customer,FirstName)%>

<%= Html.ValidationMessage("FirstName", "*")%>

</p>

In hindsight both restrictions are perfectly logic and reasonable, but it’s easy enough to do it wrong nevertheless and also quite difficult to figure out what went wrong if binding does not work. Hopefully this article will help you avoid any problems with using Custom ViewModels with POST action methods.

It seems there are no good books available on the subject yet. The few that are already in stock at Amazon are based on the community preview, and it seems that there have been quite a few changes in the the framework since then.

Fortunately, ScottGu hat just released a free sample chapter of his upcoming “Professional ASP.NET” (Wrox) book. It contains a 200-page walkthrough guide on how to build a simple ASP.NET MVC application.

The chapter is available for download here.

It’s been a while since I posted the first version of my generic base class for LINQ2SQL data layers. The idea behind this class was to provide a quick and simple way to implement a repository with LINQ2SQL and therefore also a solid foundation for implementing your n-tier architecture data layer. If you missed the article, you can read more about the base class here.

The version I previously posted has worked fine for me, but it was still lacking a way to retrieve the ID and version attributes of saved entities. Due to a typo, it also did not work with entities that have more than one unique identity column. Thanks to Mike and Fabrizio for pointing out these limitations!

Version 0.2 available here fixes both of these issues:

Download RepositoryBase Demo Website

Download RepositoryBase Source Code Only

Unfortunately, after having a closer look at LINQ, I found that using LINQ in a multi-tier application can be quite a struggle. This article shows the typical pitfalls of implementing the data layer with LINQ to SQL and provides an simple, convenient and flexible way to circumvent most of them.

The generic base class for a LINQ-to-SQL Database Abstraction Layers (DAL) that comes with this article has the following features:

• Implements the Repository pattern, allowing you to conveniently implement CRUD (Create, Update, Delete) operations with less than ten lines of code per LINQ entity type.
• Works seamlessly in disconnected LINQ mode
• Supports transparent database updates of LINQ entity hierarchies in one single database roundtrip.
• As a convenience feature, it also writes all executed SQL statements to the output console when debugging your application.

I’m going to assume that you have a basic understanding of what LINQ to SQL (also known as DLINQ) does and how it is used. If you don’t, have a look at this tutorial first and come back to this page to see how to use LINQ to SQL in multi-tier applications.

The Problem

LINQ to SQL is incredibly easy to use if you simply hook your UI layer directly to the database with LinqToDataSource objects. But that’s not very object-oriented, and certainly not an advisable architecture unless you are coding a quick and dirty application and do not plan on extending it in the long run.

Instead, most developers divide their applications into several layers, for example the following:

• Data Access Layer
• Business Layer
• UI Layer

This is known as a multi-tier database application design. LINQ to SQL would be used in the Data Access Layer.

The problem with LINQ to SQL is that – despite it’s many advantages – it’s not very simple to use when implementing the data layer.

Have a look at the following database schema:

As long as you are loading and saving LINQ entities to the same data context instance (this is known as “connected mode”), implementing your Data layer with LINQ is very straightforward.

For example, let’s fetch the customer entity with ID==1 from the database, change its first name to “Homer” and save it back to the database. In an multi-tier database application the code might be somewhere in the UI or business layer and look like this:

//create a new repository instance
CustomersRepository customersRepository = new CustomersRepository();
//load a customer instance and change it's FirstName;
Customer customer = customersRepository.Load(2);
customer.FirstName = "Homer";
//commmit customer to database
customersRepository.Save(customer);

The easiest way to implement the data layer Load and Save functions used above is this:

static DataClassesDataContext context=new DataClassesDataContext();
public Customer Load(int CustomerID)
{
return context.Customers.Single(c => c.ID == CustomerID);
}
public void Save(Customer toSave)
{
context.SubmitChanges();
}

This approach is using connected LINQ mode: The data context never goes out of scope, so it can always be reused to save entities to the database which are still connected to it.

Granted, it is convenient and works for the isolated example above, but it has severe concurrency issues because one database context is used for all database operations:
When calling Save(), SubmitChanges commits ALL changed entities, not only those related to the LINQ entity that the Save Method received in the toSave parameter.

But even setting this flaw aside, you can’t implement the data layer in the same manner when using LINQ in a multi-tier ASP.NET application. Here, chances are that your LINQ entity is loaded with the one page request, then updated and saved to the database with the next page request. Meanwhile, your original data context has gone out of scope, making your LINQ entity disconnected.

And there are also many other scenarios where you need to use disconnected LINQ mode: For example you might want to implement your Database Layer as a web service, commit previously serialized LINQ entities to your database, etc.

Implementing the data layer with disconnected LINQ to SQL

So, how do we implement a Data layer Save() method that works in disconnected LINQ mode?

We have to

• Detach the entity from the old data context
• Create a new data context
• Attach the entity to the new context
• Submit changes

In source code, it looks like this:

public Customer Load(int CustomerID)
{
DataClassesDataContext context = new DataClassesDataContext();
return context.Customers.Single(c => c.ID == CustomerID);
}

public void Save(Customer toSave)
{
//the old data context is no more, we need to create a new one
DataClassesDataContext context = new DataClassesDataContext();
//serialize and deserialize the entity to detach it from the
//old data context. This is not part of .NET, I am calling
//my own code here
toSave = EntityDetacher<Customer>.Detach(toSave);
//is the entity new or just updated?
//ID is the customer table's identity column, so new entities should
//have an ID == 0
if (toSave.ID == 0)
{
//insert entity into Customers table
context.Customers.InsertOnSubmit(toSave);
}
else
{
//attach entity to Customers table and mark it as "changed"
context.Customers.Attach(toSave, true);
}
}

Now you can load and alter as many entities as you like and only commit some of them to the database. But due to using disconnected LINQ, this implementation does not account for associations between LINQ entities.

For example, imagine you want to do the following in your business or UI layer:

//load currently selected customer from database
Customer customer = new CustomersRepository().Load(1);
//change the customer's first name
customer.FirstName = "Homer";
//add a new bill with two billingitems to the customer
Bill newbill = new Bill
{
Date = DateTime.Now,
BillingItems =
{
new BillingItem(){ItemPrice=10, NumItems=2},
new BillingItem(){ItemPrice=15, NumItems=1}
}
};
customer.Bills.Add(newbill);
//create a new provider to simulate new ASP.NET page request
//save the customer
new CustomersRepository().Save(customer);

The disconnected mode Save() method above would commit the change to the FirstName column, but simply forget about the new bill and billing items. In order to make it work, we also need to recursively Attach or Insert all associated child entities:

public void Save(Customer toSave)
{
//the old data context is no more, we need to create a new one
DataClassesDataContext context = new DataClassesDataContext();
//serialize and deserialize the entity to detach it from the
//old data context. This is not part of .NET, I am calling
//my own code here
toSave = EntityDetacher.Detach(toSave);
//is the entity new or just updated?
//ID is the customer table's identity column, so new entities should
//have an ID == 0
if (toSave.ID == 0)
{
//insert entity into Customers table
context.Customers.InsertOnSubmit(toSave);
}
else
{
//attach entity to Customers table and mark it as "changed"
context.Customers.Attach(toSave, true);
}
//attach or save all "bill" child entities
foreach (Bill bill in toSave.Bills)
{
if (bill.ID == 0)
{
context.Bills.InsertOnSubmit(bill);
}
else

{
context.Bills.Attach(bill, true);
}
//attach or save all "BillingItem" child entities
foreach (BillingItem billingitem in bill.BillingItems)
{
if (bill.ID == 0)
{
context.BillingItems.InsertOnSubmit(billingitem);
}
else
{
context.BillingItems.Attach(billingitem, true);
}
}
}
}

Not very complicated, but a lot of typing. And that’s only for a trivial database scheme and one single entity type. Imagine you were implementing the database layer for several dozen entity types with a few dozen foreign key relationships. You would have to write dozens of nested foreach loops for every single LINQ entity you need a DAL Repository class for. This is not only tedious, but also error-prone. Whenever you add a new table, you’d have to add a few dozen foreach loops to various DAL Repository classes.

How I avoided all these problems

After quite a bit of online research, I implemented a class called RepositoryBase that you can use to quickly implement your data layer that works fine with the examples shown above.

In order to use it, you must first instruct the Object Relational Mapper to generate serializable LINQ entities: Open your dbml file in Visual Studio, left-click somewhere in the white area, and set “Serialization Mode” to “Unidirectional” in the “Properties” panel:

Now you can derive from RepositoryBase to implement your own Repository:

public class CustomersRepository :
//derive from RepositoryBase with the entity name and
//data context as generic parameters
DeverMind.RepositoryBase
{
override protected Expression<Func<Customer, bool>> GetIDSelector(int ID)
{
//ID needs to be the entity's ID column name
return (Item) => Item.ID == ID;
}
}
public partial class Customer
{
public static RepositoryBase CreateRepository()
{
//create and return an instance of this entity type's repository
return new CustomersRepository();
}
}

Do this for each of your entity types, and you have a data layer working seamlessly in disconnected mode. Your derived Repository classes automatically implement the following methods:

As a small bonus, you can also see the SQL commands that were run against the database by ProviderBase in your debug output console when debugging your application. Thanks to Kris Vandermotten for the handy DebuggerWriter component, which is used by RepositoryBase for the SQL debug output!

There’s no free lunch…

There is no significant performance penalty for the Load operations, but there is a bit of reflection going on behind the scenes when you are calling the Save or Delete
methods.

For the vast majority of your DAL needs, this probably has no significant impact on your application either. However, if you are performing a lot of update / insert / delete operations, especially with lots of nested child entities involved, then you might want to hand-code your own Save / Delete functions for the Repository classes of those child applications as described above. All Save / Delete functions are virtual, so you can easily override them.

Also, please note that RepositoryBase does not support recursive save or delete operations with circular dependencies.

Conclusion

This article and the included source code provide a simple, convenient and extensible way to implement your multi-tier LINQ data layer CRUD methods. It works in disconnected mode and supports saving and loading of nested child entities. There is a small performance penalty on Save and Load operations, but you can override those for those Repositories where Save or Load performance is critical.

For everything else, you’re good to go with just a few lines of code.

Source Code

The updated source code for this article can be found here.

Feedback Wanted!

Thanks for your interest in this article. If you have any hints, questions or suggestions, please let me know. I’m using this class on a daily basis and am therefore always interested on how to improve it even further.

Most of my Linq entities have a version attribute to speed up database operations, and sometimes the entities are not only displayed, but also updated and saved back to the database. The first time I tried this, I got the following exception:

A first chance exception of type ‘System.Data.Linq.ChangeConflictException’ occurred in System.Data.Linq.dll

The reason for this is that I was not displaying the version anywhere in the Detailsview. When saving the entity back to the database, the ObjectDataSource created a new entity with default values for all properties that were not bound to any datafields in the DetailsView. So, the entity was re-instantiated with Version==null and when trying to update the database table for the Linq entity, Linq was looking for a row with a 0 version column.

I thought I might work around this by simply version property of the Linq entity to an invisible Column in the Detailsview. But that only gave me a new exception when trying to update the entity:

Sytem. InvalidOperationException: Cannot convert value of parameter ‘Version’ from ‘System.String’ to ‘System.Data.Linq.Binary’

The reason for this is that the Version attribute in Linq entities is of the type System.Data.Linq.Binary, which can be converted to a string, but not back from string to System.Data.Linq.Binary.

It took me quite a while to find at least some workaround for this problem. A working – but somewhat awkward – solution is to create a VersionString propery in each entity:

public partial class Customer
{
public string VersionString
{
get { return _Version.TimestampToString(); }
set { _Version = value.StringToTimestamp(); }
}
}

public static class DateTimeExtensions
{
public static string TimestampToString(this Binary binary)
{
return Convert.ToBase64String(binary.ToArray());
}
public static Binary StringToTimestamp(this string s)
{
return new Binary(Convert.FromBase64String(s));
}
}

Then I bound the VersionString to a hidden field in the DetailsView and the problem was gone. But this solution is not ideal since it requires the VersionString property to be defined for every single Linq entity type that uses a timestamp.

But wait, there’s a much easier way, I stumbled across this solution while playing around with Detailsview a few days ago: Simply add the Version propery to the DataKeyNames property of the DetailsGrid. For example, if your DataKeyNames propery is usually DataKeyNames=”ID”, write DataKeyNames=”ID,Version” instead.

This way the DetailsView serializes the Version property to it’s view state and deserializes it again when the entity has to be recreated. No need to fiddle with the VersionString approach above.