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.

SubSonic is an excellent open source DAL generation tool developed by Rob Conery that has been around for almost a year. In most cases SubSonic can just be added to your project, pointed to a databse, and you magically and immediately gain access to a rich and strongly typed object model that can be used to query and persist data to and from your relational data source.

SubSonic also has a cool feature called the REST handler that essentially allows one to use HTTP protocol as an interface to data stored in a back-end relational database. It is URI based and returns data back in XML format. This data can then be used by decoupled client applications as they see fit. If you have never looked at SubSonic, you owe it to yourself to checkout this very cool tool.

Recently Microsoft unveiled their plans to release similar features codenamed Astoria and Jasper with .NET framework 3.5 and Visual Studio 2008. The CTP of Astoria and Jasper are available for download from Microsoft.

Jasper is described by Microsoft as:

Project Jasper is geared towards iterative and agile development. You can
start interacting with the data in your database without having to create
mapping files or define classes. You can build user interfaces by naming
controls according to your model without worrying about binding code. Project
Jasper is also extensible, allowing you to provide your own business logic and
class model. Since Project Jasper is built on top of the ADO.NET Entity
Framework, it supports rich queries and complex mapping.

Pablo Castro, the mastermind behind Astoria describes it as:

The goal of Microsoft Codename Astoria is to enable applications to expose data as a data service that can be consumed by web clients within a corporate network and across the internet. The data service is reachable over HTTP, and URIs are used to identify the various pieces of information available through the service. Interactions with the data service happens in terms of HTTP verbs such as GET, POST, PUT and DELETE, and the data exchanged in those interactions is represented in simple formats such as XML and JSON.

The Astoria web site also includes sample online services that showcases how this new technology can be used. It also allows anyone with a Passport account to design and host their own experimental data services .

Since database are usually designed in development environments, migrating changes over to other environments (e.g. QA and production) is not a trivial task.  This is because SQL Server does not have any built-in tools to compare database schemas. 

There are quite a few third-party tools that would make your life easier, most notably, Red Gate’s SQL Compare (reasonably priced around $300).

At times, buying a commercial tool is not really an option, so one must resort to googling for free tools.  There are three such tools that I am aware of:

1. SQLDBDiff by SQLDBTools
   A very decent tool that comes in both freeware and shareware versions.  Freeware version is not badly crippled; only advanced features such as multi-database comparison, data content comparison, etc. are disabled.

2. Database Schema Comparison Utility
   This is a Code Project article that comes with C# source code of a schema comparison utility.  The utility itself is pretty bare-bone, but gets the job done.
3. StarInix Free Database Compare 2.0
   I have not used this tool, but from the advertised feature list, it looks pretty good.  Most notably, in addition to SQL Server, this tool works with Access and MySQL databases.

While SQL Server provides automatic data locking mechanism which is good enough for most situations, there are times when developers must provide locking hints in their queries for better performance. There are several locking hints that can be used with SQL Server, however, the two most common ones are as follows:

READ COMMITTED
This is the default locking strategy used by SQL Server.

PROS:
Guarantees that only committed data is read.

CONS:
If a writer has a lock in place, readers are blocked until the writer releases it’s lock, hence delaying readers.

EXAMPLE

-- Default behavior; no special hint required
SELECT EmployeeID, EmployeeName FROM Employee

NOLOCK or READ UNCOMMITTED
It is best used when approximations are acceptable, or for “dual-role” systems where database is responsible for many simultaneous reads and writes.

PROS:
Reads are blazing fast, since any exclusive locks are ignored. Also Shared Locks are not issued on rows read, so writers do not have to wait for read operations to complete.

CONS:
Data read may not be 100% accurate, since exclusive locks are ignored.

EXAMPLE

-- NOLOCK hint is used
SELECT EmployeeID, EmployeeName WITH (NOLOCK) FROM Employee

using (OleDbConnection cn = new OleDbConnection())
{
    OleDbCommand cmd;
    DataTable schemaTable;
    OleDbDataReader reader;

    cn.ConnectionString = @"Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=Northwind;Data Source=(local);";
    cn.Open();

    cmd = new OleDbCommand("Employees", cn);
    cmd.CommandType = CommandType.TableDirect;

    using (reader = cmd.ExecuteReader(CommandBehavior.SchemaOnly | CommandBehavior.KeyInfo))
    {
        schemaTable = reader.GetSchemaTable();

        foreach (DataRow row in schemaTable.Rows)
        {
            foreach (DataColumn col in schemaTable.Columns)
                Console.WriteLine(col.ColumnName + " = " + row[col].ToString());

            Console.WriteLine();
        }

        reader.Close();
    }

    cn.Close();
}

This feature can be used to develop ASP.NET or WinForms solutions that sport SQL Server Reporting Services style reports, without having to deploy those reports to a Reporting Server. Reports are deployed as RDLC files with your solutions. In fact one doesn’t even need SQL Server, since these reports can be programatically bound to objects such as DataSets, a huge plus for ditributed n-tier designs where the UI layer does not have direct access to the data store. This also means that one can use any imaginable back-end data store including XML and CSV files as long as data can be loaded into binable objects.

The report viewer control is similar to Reporting Services report viewer, with nifty features such as paging, searching, and export (PDF, Excel, CSV) features. My only complain with the ASP.NET version of the report viewer is that it does not directly support printing. Reports have to be exported to PDF in order for one to print. This was a gotcha with the first versions of Reporting Services report viewer as well, but later they added printing support to the control (perhaps through ActiveX) in Reporting Services SP1.

You can find more information about this feature at GotReportViewer.

Configuring Role and Membership Providers:

Essentially everything is configured declaritively using Web.config:

In the above configuration file, note that we first specify our connection strings starting at line 2. LocalSqlServer points to a SQL Server database which has been configured using aspnet_regsql. The second connection string points to the domain controller for membership authentication.

In the authentication section we specify that we are using forms authentication, and provide the URL for our logon page.

In the roleManager section we configure our role provider, pointing back to LocalSqlServer as the role repository.

In the membership section we configure our membership provider pointing back to ADConnectionString (domain controller) specified in the connectionStrings section.

Finally we restrict users from accessing certain folders based on their roles using location sections (role-based security).

EXEC sp_dropserver 'Your_OLD_Computer_Name'
GO

EXEC sp_addserver 'Your_NEW_Computer_Name', 'local'
GO

Restart your SQL Server service. Connect using Query Analyzer and run the following command (It should output the new server name):

SELECT @@SERVERNAME
GO