The World’s Leading Microsoft .NET Magazine
   
 
The .NET Addict's Blog

My Top Tags

                                                           

My RSS Feeds








Latest Diggs - Programming

Internet Blogs - Blog Top Sites

Site Hits

Total: 2,551,611
since: 19 Jan 2005

Taking advantage of the partial class with the ADO.NET Entity Framework

posted Tue 25 Mar 08

So you're building your data-driven application and you've got an ADO.NET Entity Model that represents an abstraction around your database. Maybe you're even pretty savvy and you've used inheritance and some filters to enhance the entity model so that it really is an entity model and not just a raw translation of your database schema into objects. One thing that I have noticed is that in a lot of sample code, a lot of utility functions end up being put in inefficient locations because people forget that the entity model is a partial class. This means that you can extend the model with your own properties and methods.

For example, what if you want to implement a keyword search throughout your entity model and you know that you will probably have multiple entry points in your application utilize that search function. You could probably create a class called EntityTools or some such and create a method called Search(string keyWord) , but there's a better place to put that - right in the model!

Take a look at this method:

public List<Customer> Search(string keyWord)
{


    // also do whatever other normalization you want like removing filler words, etc

keyWord = keyWord.ToLower();
    var query = from Customer cust in this.Customers
        where cust.FirstName.Contains(keyWord) ||
            cust.LastName.Contains(keyWord) ||
        cust.OrderItems.Any ( oi => oi.LineItem.Description.Contains(keyWord)
        select cust;
      return query.ToList();
}

So.. now you can write code that consumes your model like this:

using (CustomerEntities ci = new CustomerEntities())
{
    List<Customer> searchResults = ci.Search("bob");
}

Not only is this easier to follow and easier to read, but its easy to maintain and you can re-use those same methods for any entity model that happens to have the same or similar schema. You can also define custom properties that expose data in a specific way that you know you will be querying frequently:

public IQueryable<Customer> PastDueCustomers
{
    get {
        return from Customer cust in this.Customers
            where cust.OrderItems.Sum ( oi => oi.Amount ) > 0
            select cust;
    }
}

This code automatically creates a queryable property of customers that have unpaid balances remaining in their line item lists. Can you imagine having to do subqueries of Past Due Customers, for example, sorting the list of past due customers by their past due amount and then sub-filtering that list by those customers who are not on the 'Premier' advantage plan yadda yadda. You can use PastDueCustomers as a query source, like this:

var reallyComplicatedQuery = from Customer cust in ci.PastDueCustomers ....

So, the next time you go to add additional business logic to your model or you need some utility methods, consider putting them in a partial class that is the same name as your model in the same namespace as your model and you may just find that your ADO.NET EF experience got a little more pleasant.

tags:          

links: digg this    del.icio.us    technorati    reddit




Tag Related Posts

Orcas EDM Wizard Patched

Fri 27 Apr 07 11:56 A GMT-05
tags:      

Visual Studio "Orcas" - March CTP is Available

Wed 28 Feb 07 12:28 P GMT-05
tags:            

ASP.NET vs Ruby on Rails : Round 2 (Agility)

Thu 05 Oct 06 11:02 A GMT-05
tags:                      

ASP.NET vs Ruby on Rails : Round 1

Wed 04 Oct 06 1:37 P GMT-05
tags:                

ADO.NET Entity Framework Announced Today!

Wed 16 Aug 06 11:08 A GMT-05

DLinq vs the ADO.NET Entity Framework

Fri 23 Jun 06 4:01 P GMT-05