DevEducate Blog

Understanding Azure Events - PowerPoints available

rob@robbagby.com — Mon, 25 Apr 2011 22:50:00 -0500

Between April 11 and April 21, myself and Bruno Terkaly delivered ‘Understanding Azure’ events in 7 cities:

April 11: Denver
April 12: San Francisco
April 15: Tempe
April 18: Seattle (Bellevue)
April 19: Portland
April 20: Irvine
April 21: Los Angeles

These were 4 hour events where we covered the gamut of services offered in Azure. I spent the first 3 hours covering Windows Azure. I illustrated how to host services in Azure and how to take advantage of Windows Azure Blob, Queue and Table storage, showing both the REST, as well as StorageClient APIs. Bruno showed off the AppFabric in the last hour.

My portion of the presentation was a subset of the Azure Training available online on this site.

The powerpoints for the event are available to download here:

Twas the Release Before Christmas

rob@robbagby.com — Wed, 15 Dec 2010 06:13:00 -0500

Twas the release before Christmas
And all through the App
There was random data access code,
It was looking like crap.

Connections were carelessly
Left open everywhere.
Others might think
That I didn’t care.

I needed to put an end
To this custom coding.
I needed to support
Concurrency and Lazy Loading.

I wrote so much SQL
I could hardly think.
God how I wished
My DAL supported LINQ.
Read More...

Index of Entity Framework Posts and Screencasts

rob@robbagby.com — Tue, 14 Dec 2010 07:46:00 -0500

I am in the process of doing a brief series of blog posts and screencasts on the ADO.NET Entity Framework. This page will serve as an index. I will keep it up to date.

Blog Posts

Screencasts

Entity Framework Modeling: Table Splitting

rob@robbagby.com — Tue, 14 Dec 2010 07:37:00 -0500

Table Splitting involves mapping multiple entities in the conceptual layer to a single table in the store. There are a few scenarios where this is useful. The most common is that a table may contain a large column that may not be used frequently. This could be an image, other binary data, xml … The net-net is that you do not want to always return this beast when fetching an entity. If / when you want it you can load that relationship using eager, explicit or lazy loading.

A second scenario is that you want to split the data among 2 entities for conceptual reasons. Perhaps you only want certain consumers to have access to certain kinds of data. In this post, I will illustrate the first scenario, as it is more common.

Watch the Screencast

Entity Framework Modeling: Table Splitting

Blog Series Index

Index of Entity Framework Posts and Screencasts

The Scenario

Below you can see the Employees table in Northwind. As you can see, it has an image column named Photo. It also has an nvarchar column storing a path to an image (not sure why it has both). In this demo, I’ll spilt both columns off into a separate entity named EmployeePhoto.

Implementing Entity Splitting

Step 1: Create a console application. I named mine TableSplitting.

Step 2: Add the Entity Data Model. I named mine NorthwindModel

Generate the model from the database.

Choose the Nortwind connection (or create one, if you need to). Don’t forget to set an appropriate name to the “entity connection settings”, as this will be the name of your context. I use the naming convention <Domain>Context, so mine is named NorthwindContext.

Add the Employees table.

Your conceptual model will look like this:

Step 3: Copy the Employee entity

Simply single-click on the Employee entity and press ctrl+c. Then click on some whitespace in the model and press ctrl+v. You should see something like the following:

Step 4: Rename the Employee1 Entity and delete the appropriate properties

Rename this entity to EmployeePhoto. Then delete every property from the entity except the following (you can single click or multi-select properties and press the delete key):

EmployeeID
Photo
PhotoPath

It should now look something like this:

Step 5: Delete the Photo and PhotoPath properties from the Employee Entity

Select the Photo and PhotoPath properties from the Employee entity and press the delete key.

Step 6: Map the EmployeePhoto entity to the Employees Table

Right-click the EmployeePhoto entity and choose “Table Mapping”

Choose to map this entity to the Employees table.

Because the property names line up with the table column names, you do not need to do anything else. Notice that the EmployeeID, Photo and PhotoPath properties are mapped to the appropriate table columns:

Step 7: Add a 1:1 Association between the Employee and EmployeePhoto entities

Right-click the EmployeePhoto entity, choose “Add” and choose “Association…”

Make sure the multiplicity between the 2 entities is 1:1 like below:

Step 8: Add a referential constraint between the Employee and EmployeePhoto entities

Double-Click the association line to bring up the referential constraint dialog. Choose the Employee as the principle and press OK.

This created a referential constraint in the conceptual layer. You can look at it by saving the model, closing the designer and opening the edmx with an XML Editor.

Scroll down to the Association Element in the CSDL and you can see the referential constraint.

Testing the Model

Write the following code in your SVM:

static void Main(string[] args)

{

using (NorthwindContext context = new NorthwindContext())

{

var employee = (from e in context.Employees

select e).FirstOrDefault();

Console.WriteLine(employee.LastName);

Console.WriteLine(employee.EmployeePhoto.Photo.Length.ToString());

}

Console.ReadLine();

}

If you run it, you get the expected result:

Taking a look at SQL Profiler, you can see that the original query did not return the Photo or PhotoPath columns.

You can also see that, when we accessed the EmployeePhoto entity, Lazy Loading kicked in and a query was sent to the server to fetch the Photo and PhotoPath columns. Have a look:

Using Eager Loading

We didn’t have to use Lazy Loading to fetch the related EmployeePhoto entity. If I knew that I needed to access the EmployeePhoto with the Employee, I could simply use Eager Loading. have a look at the following code. The only difference is that I added an “Include” statement.

using (NorthwindContext context = new NorthwindContext())

{

var employee = (from e in context.Employees.Include("EmployeePhoto")

select e).FirstOrDefault();

Console.WriteLine(employee.LastName);

Console.WriteLine(employee.EmployeePhoto.Photo.Length.ToString());

}

Console.ReadLine();

If I clear profiler and run the code again, notice that only one query is now run and that the Photo and PhotoPath columns are returned.

Conclusion

The tooling in Entity Framework 4 makes short work of Table Splitting.

Partial Classes Naming Convention in the Entity Framework

rob.bagby@deveducate.com — Tue, 30 Nov 2010 15:00:00 -0500

You are likely aware that the classes generated by the T4 templates provided by the Entity Framework (EntityObject, POCO, Self-tracking entities) are implemented as partial classes. This allows you to implement your custom business logic in another (or multiple) partial class(es) and your code will not be overwritten if/when you make changes to your model. It is a nice pre-compile feature that allows you to split your class across multiple files.

The question comes up though, how to name these partials. Read More...

Azure Blob URIs are case sensitive–just ask your shrink

rob@robbagby.com — Tue, 23 Nov 2010 15:34:00 -0500

If you have worked with Azure Blobs before, you have undoubtedly run into this. If you are like me, you spent 30 minutes or so trying to access a blob and getting a big fat 404. You probably initially assumed that it was a permissions issue (it almost always is), only to find out that blob URIs are case sensitive.

Did that / should that piss you off? To answer that question, I’m going to give you a rare glimpse into my world. The following is an excerpt from a therapy session between myself and my shrink. Read More...

Implementing Lazy Loading For My POCO in Entity Framework 4

rob@robbagby.com — Wed, 17 Nov 2010 11:41:00 -0500

In a previous post, I provided a simple end-to-end example where I used the Entity Framework designer to generate an Entity Data Model (EDM), I turned off the default code generation and implemented my own POCOs. Everything worked fine, but at the end of the post I pointed out that I no longer had the Lazy Loading capability I had with the designer generated objects (a.k.a EntityObjects)..

Get the Sample Code

You can download the sample code here.

Lazy Loading for POCOs

At this point, I have a few POCOs which, by their nature, are very simple classes, as well as my context object. See the Customer class below: Read More...

Is Lazy Loading in EF 4 Evil or the Second Coming?

rob@robbagby.com — Thu, 11 Nov 2010 05:06:00 -0500

(As you probably know) The Entity Framework provides you with various options for loading related entities. In Entity Framework 4, you have the choice to implement eager loading, explicit loading and now… lazy loading. Lazy loading was not available in version 1. A quick search on ‘Lazy Loading’ will yield opinions from 2 very different camps. Some folks see lazy loading as a necessity for an ORM, while others believe it to be evil. So, who is right? This post will examine that question. If you are not familiar with what all of the load options are, I will start the post with a brief description of each.

The Code Scenario

We will use the following simple scenario to examine the various load options. In this scenario, we have 2 entities that we are surfacing as objects: Customer and Order. Each customer has 0 to many orders. Imagine the following code accessing the customer and it’s orders (in this case in a console application):

using (NorthwindContext nw = new NorthwindContext())
{
    var query = from c in nw.Customers
                where c.CompanyName.StartsWith("A")
                select c;

    foreach (Customer c in query)
    {
        Console.WriteLine("{0}", c.CompanyName);

        foreach (Order order in c.Orders)
        {
            Console.WriteLine("\t{0}", order.OrderDate.ToString());
        }
    }

    Console.ReadLine();
}

For the sake of this example, assume that we have 3 customers, with a total of 24 orders between them. Read More...

POCOs in Entity Framework 4 - Overview

rob@deveducate.com — Tue, 09 Nov 2010 13:37:00 -0500

Entity Framework 4 provides a ton of support for working with POCOs. To start with, there is T4 Template support to automatically generate POCO classes (along with a context object). There is also support for implementing higher-order functionality in your POCOs (change tracking, lazy loading, relationship fix-up) without compromising the POCOness of your objects. This is done through proxy objects.

I thought I might examine the topic of POCOs in Entity Framework 4 in detail over a few posts. In this post, I’ll illustrate high-level POCO support in EF4 without taking advantage of any templates. In future posts, I’ll look at the templates, POCOs with proxies, as well as how you might support (or pesudo-support) some of those higher-level features without Proxies.

What are POCOs?

If you’re reading this, you probably already know that POCO refers to “Plain Old CLR Objects”. These are simple objects that are free of any framework dependencies. POCO objects do not have to inherit from specific classes, do not have to implement specific interfaces, nor do they require any specific attributes. They are simple, lightweight objects that are used to pass data around. Read More...