My source object exposed some simple properties as well as a generic List property of another type.  My target object had same simple properties, but the generic List property was of an interface type.  Following is a simplified illustration of my source and target objects:

Source Object

Target Object

A cool thing about AutoMapper is that when it encounters a target object of an interface, it automatically generates a dynamic proxy class using Castle Dynamic Proxy.  This is usually the desired behavior when mapping to a non-existent target class.  In my case, however, the target class already existed, and dynamic proxy was just an overhead.  I tinkered with AutoMapper mappings to actually map to my existing target rather than generating a proxy:

Essentially what I am doing in my mapping is to first create a map between my source and target Orders objects. Once that’s done, I create a map between my source and target Customer objects but provide a custom map for the Orders property. In my custom map I simply use AutoMapper to map my source Orders property to target Orders property using the map definition I provided earlier (lines 1-2 above). This works out great and I get my expected target object without incurring the overhead of expensive proxies.

The first version of Entity Framework was introduced with .NET Framework 3.5 SP1 and Visual Studio 2008 SP1.  While the intention was great, most of everyone that I know, including my own self who have ever tried using EFv1 for anything except trivial data access have developed a love-and-hate relationship with it.  The first version looked great at first, but turned out to be an immature product at best with severe restrictions as well as quite a few bugs.

With .NET 4 Microsoft released a new version of Entity Framework that has addressed many of the issues and made it a much more stable technology.  Amongst other things, Microsoft heard developer community at large and provided POCO support in EFv4.

POCO Support – At Last!

The biggest problem with EFv1 was that the domain classes had to be tightly integrated with EF.  Essentially these classes were generated from entity models and developers had no control over code generation.  This limitation didn’t fly very well with most developers, since we like to keep our domain classes generic enough to where we can easily migrate them to any underlying data access technology.  This is especially true since the data access technologies tend to change every so often.

In EFv4 Microsoft has gone to great lengths to support Plain Old CLR Objects (POCO), which is just a fancy name for simple .NET classes with properties that can be used as Data Transfer Objects (DTO) or simply Domain Objects.

POCO classes can be handwritten and easily hooked in to EFv4.  Better yet, EFv4 allows us to generate these classes based on our entity models.  Also we have complete control over code generation since EFv4 uses T4 templates.  Speaking of T4 templates, they can also be used to generate ObjectContext classes for our entity models.

Lazy Loading, Explicit Loading, and Eager Loading

In EFv1 the only way to automatically load related entities was using eager loading.  Essentially eager loading is a LINQ technique that allows loading related entities in one shot using the Include method on the LINQ query.

EFv4 allows for lazy loading on POCO’s.  The only requirement for this added functionality is that navigation properties on POCO’s be marked as virtual and LazyLoadingEnabled property of ObjectContextOptions be set to true.  The way EFv4 does this is very cool.  Essentially it generates dynamic proxies overriding the virtual properties on POCO’s and uses those proxies instead of the POCO classes at runtime.

In addition to eager and lazy loading, EFv4 allows explicit loading of related entities.  Explicit loading allows us to explicitly load related entities on demand whenever the need arises.  Using explicit loading is as easy as calling the LoadProperty method of the ObjectContext using  the parent entity as well as the navigation property name as parameters.

Change Tracking

EFv4 supports two different types of change tracking which are as follows:

Snapshot Change Tracking.  Using this kind of change tracking is more efficient in most cases but it might require a few additional lines of code.  When using snapshot change tracking (default behavior in EFv4), the developer must make explicit call to ObjectContext’s DetectChanges method in order for the EF change tracker to notice any data that has been changed on the entity since it was first retrieved.  Also calling the SaveChanges method of the context automatically detects any changes to entities involved.

Real-time Change Tracking.  Using real-time change tracking the tracker keeps track of all data changes to entities in real-time.  For real-time change tracking to work for POCO’s, all properties of POCO’s should be marked as virtual.  Also any navigation properties should have return types of ICollection<T>.  Once these two conditions are met, EFv4 automatically generates dynamic proxies and uses them instead of the POCO’s and tracks changes made to data contained within those entities in real time.

Design Techniques

EFv4 allows a couple of different design techniques that ought to satisfy most situations.

Model First.  For new projects where that database design is not already set in stone or is non-existent, model-first approach is more natural to most developers and makes a lot of sense.  What this entails is that the developer creates an entity model using the Entity Model Designer for the domain objects involved.  This model can be easily changed during the design phase or the early development stages.  Once the architect/developer is happy with the entity design, he/she can use EFv4 to generate the data model using EFv4’s Data Definition Language (DDL) generation capabilities.  Not only that this is a more natural way of designing data access and domain model for a given solution, it’s more agile in that the model can easily be modified using a GUI tool.  Also as long as the underlying database is supported by EFv4, the developer need not worry about the exact syntax of the DDL as it can automatically be generated.  Once again the generation of DDL can be influenced using T4 templates.

Database First.  This technique is more suitable for when a project involves an existing database.  In such cases EF can easily generate domain models based on database schema.  This design technique is not new to EFv4 as it has been available since the first version of EF and this is probably what most of us are most familiar with.

Code Only.  EFv4 introduced another design technique which requires no models to be created.  Essentially there are only code classes and EF infers the model from them.  Entire database including all required tables can be generated by EF at run-time.

There’s a lot more to EFv4.  What I have covered in this article only addresses a bit of POCO support in EFv4 since that has been the number 1 request of the development community since EFv1 was released.

The presentation turned out to be pretty cool. I think WCF RIA Services provides a very neat way to design n-tier apps without much hassle as it takes care of much of the heavy lifting for you providing very easy data validation, authentication, and role-based security amongst other awesomeness.  Also through code projection it automatically allows shared code between UI and the service tier, which makes it easy to write code once and use it cross-tier.  While WCF RIA Services can be used with any front-end, e.g. WinForms and ASP.NET, it really shines when combined with a Silverlight front-end.  The best part of the technology is automatic batch updates, which is really neat.

Download and Install

1. Install WCF RIA Services for Silverlight 4
   • Install WCF RIA Services for Silverlight 4 and Visual Studio 2010
   • Install the WCF RIA Services Toolkit
   • If you already have the Silverlight 4 Tools and Visual Studio 2010 installed you can download WCF RIA Services V1.0 directly
2. Install WCF RIA Services SP1 Beta for Silverlight 4
   • Install WCF RIA Services SP1 Beta for Silverlight 4 and Visual Studio 2010
   • Install the WCF RIA Services December 2010 Toolkit for WCF RIA Services SP1 Beta

ScottGu  just made available a free downloadable eBook in PDF format as well as a simple and easy-to-understand sample project called Nerddinner.

The eBook is actually a chapter from his upcoming book on MVC, but it is an end-to-end tutorial that walks through building a small but complete ASP.NET MVC application from scratch.

Download eBook.

Download Nerddinner sample code.

Buy ASP.NET MVC 1.0 Book at Amazon.com. 

If you do decide to read this book, please do not forget to share your thoughts with me.

In the last couple of years I have noticed a steadily growing interest in the .NET community around the Inversion of Control (IoC) and Dependency Injection (DI) patterns.  This is partly due to the fact that a number of excellent frameworks have emerged and gained popularity that allow us to use these designs in our applications relatively painlessly.  One such framework is the open source Castle Project.  In my opinion Castle is the best implementation of IoC and DI among many others that I have come across including Spring.NET, NInject, and ObjectBuilder.  This is however my opinion; which framework you use largely depends upon your requirements and your preferences.

If you are just getting started with Castle or are curious about why the heck one should use IoC and DI, I strongly suggest you check out the 3-part article series by Simone Busoli.  I just came across these articles and I can’t stress enough how well they are written.

Clients should not be forced to depend on methods that they do not use.

In other words, this principle states that if a class performs multiple functions that may be used by different client classes, then those functions should be seperated out into different interfaces according to their usage.

The idea behind this principle is to confine the aount of rework to only clients that use a certain interface, should the interface of a depended-upon class changes.

While workflow capability has been available to developers using BizTalk Server and other third-party products, WF provides a single platform and programming model for Microsoft products (e.g. Office) and non-Microsoft products (developed using .NET) making workflow more of a mainstream paradigm.

In it’s simplest form, the workflow-based programming model consists of a set of business activities along with repetition and conditional logic that is modelled using some sort of a user interface. At run-time, the conditionals are evaluated and activities are executed based on the modelled workflow. If you have ever created a SQL Server DTS or SSIS package then you are already familiar with workflow-based programming model.

Some of the advantages of workflow-based programming include durability, transparency, and tolerance to dynamic change. It allows for rule-based programming and supports a declarative model which allows for easy modelling and modification of business processes.

WF nicely integrates into Visual Studio offering a rich design-time and debugging environment. Workflows can be hosted by any .NET executable assemblies including Win Forms and ASP.NET applications. WF comes with an array of built-in activities e.g. Code, Delay, Invoke, Throw, Suspend, etc., but the best part is that custom activities can be created as simply as deriving from the Activity base class and overriding the Execute method. Even composite activities can be created providing a rich and extensible programming model.

The Activity Framework in WF provides several of out-of-the-box services such as transactions, compensation, serialization, etc. Other services can be added as desired. For example, by default workflows are persisted using XAML, but if needed custom serialization may be added.

In conclusion, WF provides a very rich and highly extensible workflow-based programming model. With the passage of time we shall witness more and more Microsoft and non-Microsoft products using the WF to build and enhance applications that could use workflow functionality in new and innovative ways. As they say in French, the best is yet to come!

With such a diverse array of distributed technologies already floating around, each one with a distinct benefit, Microsoft decided to unify these technologies under a single unified platform that would not only simply developers’ lives but also pull in the benefits of all such existing technologies into one.

ASP.NET web services, for example, offer ease of programability, WSE offers security, System.Messaging offers guaranteed delivery of asynchronous messages, Enterprise Services offers attribute based transaction support, and yet .NET Remoting offers transparent use of objects. WCF unifies all these benefits and more such that the code base remains the same, while depending upon the requirements, features such as transactions can be configured mostly through XML configuration settings.

WCF is based on Microsoft’s vision of Service Oriented Architecture (SOA), where developers shall be able to combine multiple services (could be cross-platform and cross-vendor) to invent software applications that have not yet been possible.

WCF is based on a well-thought-out design where services and clients define one or more end-points. Each end-point defines the address, binding, and contract (ABC) which can be configured independently, but work together to provide a distributed message-oriented communication infrastructure.

WCF runs on Windows Vista, XP and 2003. Beta versions of .NET Framework 3.0 (including WCF) can be downloaded from Microsoft.

• High-level modules should not depend on low-level modules. Both should depend on abstractions.
• Abstractions should not depend on details. Details should depend on abstractions.

Essentially what this principle means is that in a tiered design, higher level modules and lower level modules should not directly depend on each other; instead they should only depend on abstractions. Moreover, abstractions should not have any knowledge of details (other classes in the system).

This principle closely relates to some of the other design principles I discussed previously in that it yields a design that is highly decoupled ensuring that minor changes in one part of the application do not cause a domino effect in other parts of the application. Moreover such a design is extensible — as new business entities are added, usually such as design scales well by requiring only new code to be added rather than existing code to be modified. ASP.NET 2.0′s Provider Model is a great example of such a design that provides a default implementation for various sub-systems such as Membership, Personalization, Navigation, etc. but also allows developers to modify the default behavior by extending certain classes.

Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.

What it means is that if S is a subtype of T, then a function q(x) must behave in the same manner irrespective of the type of x whether it be S or T. In other words, if a piece of code behaves differently for a subtype than a supertype, then that code violates the LSP (and consequently the OCP).

Let’s say that we work for a bank and that we have a simple teller application. Currently the teller application works with checking and savings account types.

public abstract class Account
{
    public abstract double CurrentBalance { get; }
    public abstract void Deposit(double amount);
}

public class CheckingAccount : Account
{
    private double _currentBalance;

    public override double CurrentBalance
    {
        get { return _currentBalance; }
    }

    public override void Deposit(double amount)
    {
        _currentBalance += amount;
    }
}

public class SavingsAccount : Account
{
    /* Savings account implementation */
}

Our bank just entered the mortgage business so we need to modify our teller application to support this new account type. During the short analysis phase we decide that since mortgage account is type of an account (IS-A relationship), we can simply create a new mortgage class deriving from the Account abstract class, override a method and a property, and we should be in business. We add a new class as follows:

public class MortgageAccount : Account
{
    private double _currentBalance;

    public override double CurrentBalance
    {
        get { return _currentBalance; }
    }

    public override void Deposit(double amount)
    {
        _currentBalance -= amount;
    }
}

Everything sounds logical, that is until we come across this code in the teller application:

public class Bank
{
    public void ReceiveMoney(Account account, double amount)
    {
        double oldBalance = account.CurrentBalance;
        account.Deposit(amount);
        Debug.Assert(account.CurrentBalance = oldBalance + amount);
    }
}

Based on our pre-existing code, the ReceiveMoney() method is making a reasonable assumption that the new balance should be equal to the old balance plus the newly deposited amount. This assumption is, however, violated if we pass an instance of the Mortgage class to this method. This is a clear violation of the LSP.