DevEducate Blog - Simplifying the Complex

Understanding Azure Events - PowerPoints available

posted by rob@robbagby.com - April 25, 2011 - Comments (0)

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:

Tags: ,

Twas the Release Before Christmas

posted by rob@robbagby.com - December 15, 2010 - Comments (0)

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...

Tags:

Index of Entity Framework Posts and Screencasts

posted by rob@robbagby.com - December 14, 2010 - Comments (1)

Entity Framework Modeling: Table Splitting

posted by rob@robbagby.com - December 14, 2010 - Comments (5)

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.

image

Implementing Entity Splitting

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

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

SNAGHTML51ead2a

Generate the model from the database.

SNAGHTML51fc146

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.

SNAGHTML520887b

Add the Employees table.

SNAGHTML524e192

Your conceptual model will look like this:

image

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:

image

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:

image

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.

image

Step 6: Map the EmployeePhoto entity to the Employees Table

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

image

Choose to map this entity to the Employees table.

image

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:

image

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

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

image

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

SNAGHTML53cb1fb

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.

image

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.

image

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

image

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:

image

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

image

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:

image

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.

image

Conclusion

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

Partial Classes Naming Convention in the Entity Framework

posted by rob.bagby@deveducate.com - November 30, 2010 - Comments (0)

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

posted by rob@robbagby.com - November 23, 2010 - Comments (0)

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...

Tags: , ,

Implementing Lazy Loading For My POCO in Entity Framework 4

posted by rob@robbagby.com - November 17, 2010 - Comments (0)

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?

posted by rob@robbagby.com - November 11, 2010 - Comments (3)

(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

posted by rob@deveducate.com - November 9, 2010 - Comments (1)

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...