Managing Entity Framework ObjectContext lifespan and scope in n-layered ASP.NET applications

Total votes: 8
Views: 70,868
Comments: 49
Category: ADO.NET
Print: Print Article

Please login to rate or to leave a comment.

Published: 23 Dec 2008
By: Jordan Van Gogh
Download Sample Code

Jordan van Gogh describes a way to manage ObjectContext lifespan and scope in the Business Logic Layer (BLL) of a small to medium sized ASP.NET web application.

Contents [hide]
1 Introduction 2 The problems of working with multiple ObjectContext instances 3 One shared static ObjectContext 4 One shared ObjectContext instance per HTTP request 5 One ObjectContext instance per business transaction 6 Sample Application 6.1 Northwind.DataLayer.Model 6.2 Northwind.BusinessLayer.Facade 6.3 Northwind.BusinessLayer.Facade.Tests 6.4 Northwind.Framework.ObjectContextManagement 7 Managing ObjectContext instantiation

Contents [hide]

1 Introduction
2 The problems of working with multiple ObjectContext instances
3 One shared static ObjectContext
4 One shared ObjectContext instance per HTTP request
5 One ObjectContext instance per business transaction
6 Sample Application

6.1 Northwind.DataLayer.Model
6.2 Northwind.BusinessLayer.Facade
6.3 Northwind.BusinessLayer.Facade.Tests
6.4 Northwind.Framework.ObjectContextManagement

7 Managing ObjectContext instantiation

Introduction

Since the introduction of the ADO.NET Entity Framework, I've been looking for ways on how to incorporate this new technology in a typical n- layered ASP.NET application. I've started off by replacing the traditional - mostly handwritten - Data Access classes (DAL) with a database generated Entity Data Model (EDM). This offers some great benefits, for example by speeding up development time, and reducing the number of bugs in the DAL.

The middle layer – or Business Logic Layer (BLL) as I like to call it - classes remain effectively the same as in the .NET 2.0 days. The only difference is in how they use the Data Access objects, which needless to say reside in the Data Access Layer (DAL). Instead of referencing their counterpart DAL classes (for example the ProductBLL class methods may call data access methods in the ProductDAL class), the BLL classes now use an instance of an ObjectContext for their data access purposes. In this role, the ObjectContext class replaces the more traditional DAL classes.

Up till now everything I've described has been pretty straightforward. However, some problems may arise when you start to think about how to use an ObjectContext in a scenario where you have multiple BLL classes, and you want to be able to exchange business objects (i.e. domain entities) between instances of those classes. Since all changes are tracked by an ObjectContext (instead of by the objects themselves), it's not always easy to "mix" objects that originate from different ObjectContext instances. However, there are several ways to share ObjectContext instances between BLL classes within the BLL. Each with its own advantages and disadvantages.

One way to do it for example, is to use a single ObjectContext for each business transaction (in a Unit of Work pattern). Another way to do it, is by globally sharing a single ObjectContext instance between all BLL classes. Each of these methods will be discussed in more detail later in this article.

The problems of working with multiple ObjectContext instances

Like I mentioned in the introduction, working with multiple instances of an ObjectContext class simultaneously can be a bit troublesome. In the Entity Framework changes are tracked by an ObjectContext instance, instead of by the business objects/entities themselves. To be able to define and save a relationship between objects that originated from different ObjectContext instances, you would first have to “detach” an entity (i.e. business object) from its originating ObjectContext instance, and then “attach” it to the ObjectContext of the other entity. For example:

NorthwindObjectContext objectContext1 = new NorthwindObjectContext();
Categories category = objectContext1.Categories
                                    .FirstOrDefault(c => c.CategoryID == 1);
NorthwindObjectContext objectContext2 = new NorthwindObjectContext();
Products product = objectContext2.Products
                                 .FirstOrDefault(p => p.ProductID == 1);
/* Detach from originating ObjectContext: */
objectContext1.Detach(category);
/* Attach to the other ObjectContext: */
objectContext2.Attach(category);
/* Define a relationship between the category and product objects: */
product.Categories = category;
objectContext2.SaveChanges(); 

Moreover, the Detach() method only detaches the object that was supplied as an argument. It does not automatically detach related objects.

The code sample above is just a demonstration of the concept of “detaching” and “attaching” entities. Obviously, I could have just loaded both the category and product objects from the same ObjectContext instance, and thus avoiding any problems whatsoever. This is also true for projects that query an Entity Data Model (EDM) directly in their Presentation Layer (in for example the code behind files). However, in my projects – no matter how small – I always use a middle layer (BLL) to store my LINQ-to-Entities queries and business logic. It’s my preferred way of working, because it promotes maintainability and extensibility. It also allows me to unit test my code.

Working with a middle layer (BLL) also means that you will be dealing with multiple BLL classes. There will probably be a separate BLL class for each of your business objects (i.e. domain entities). For example if we look at our code sample above, we might have created a ProductsBLL and a CategoriesBLL class. Business objects returned from instances of those classes, may define relationships with one another. Persisting these relationships will result in an exception being raised if both of the BLL classes use different ObjectContext instances. So we have to either make sure that both of the BLL classes use the same ObjectContext instance, or that we have “manually” tied the objects who defined the relationship to the same ObjectContext instance.

Writing code for attaching and detaching entities in a n-layered ASP.NET application can sometimes become a bit cumbersome, and moreover it’s often unnecessary. There are several good ways of sharing your ObjectContext instances among your BLL classes. In the sections that follow, I will discuss a few of these ways in detail. In the sample code that I have provided, I’ve also included a small generic framework for managing ObjectContext instantiation in your middle layer classes.

One shared static ObjectContext

Lets first start off with a way of sharing an ObjectContext that isn’t suitable for ASP.NET webapplications. I’ve read a lot of forum posts on the internet, in which developers tend to use an ObjectContext as a static class member. In this way the ObjectContext can be globally shared between all classes that use it. It offers some great flexibility, since all business objects/entities in the application originate from the same ObjectContext instance.

Listing 1: Using a static ObjectContext

private static NorthwindObjectContext _objectContext;
/// <summary>
/// Returns a shared static NorthwindObjectContext instance.
/// </summary>
public NorthwindObjectContext ObjectContext
{
    get
    {
        if (_objectContext == null)
            _objectContext = new NorthwindObjectContext();
        return _objectContext;
    }
}

However, you shouldn’t use a static ObjectContext in an ASP.NET application, since static members have a lifespan beyond that of a single HTTP request. They’re actually bound to the lifespan of the AppDomain, which might be minutes or hours. In fact, static class members in ASP.NET are even shared between multiple threads and users of the application. Using the same ObjectContext instance from within multiple threads simultaneously can cause serious problems.

It’s also generally accepted that ObjectContext instances should have a short lifespan, so keeping an ObjectContext around for minutes or even hours is probably not a good practice. But if you’re looking for the flexibility that is provided using a static ObjectContext, then have a look at the solution that is presented in the next section.

One shared ObjectContext instance per HTTP request

Since sharing an ObjectContext as a static member in an ASP.NET application is a no-go, we have to find some other way to achieve similar flexibility. To do this we have to somehow store an ObjectContext instance in a central place for the lifespan of one - and only one - HTTP request. This is where the HttpContext.Current object comes into place.

The Items property of the HttpContext.Current object is a Hashtable for storing objects on a per-request basis. All of your BLL (middle layer) classes have access to this property, so this is a place in which we can store an ObjectContext instance, and then share it between all instances of those classes.

Listing 2: Using the HttpContext.Current.Items property

/// <summary>
/// Returns a shared ObjectContext instance.
/// </summary>
public NorthwindObjectContext ObjectContext
{
    get
    {
        string ocKey = "ocm_" + HttpContext.Current.GetHashCode().ToString("x");
        if (!HttpContext.Current.Items.Contains(ocKey))
            HttpContext.Current.Items.Add(ocKey, new NorthwindObjectContext());
        return HttpContext.Current.Items[ocKey] as NorthwindObjectContext;
    }
}

It’s a good practice to use a “Lazy Load” pattern in this scenario, so that we only create a new ObjectContext instance when we actually need one.

By globally sharing an ObjectContext instance between classes on a per-request basis, you’ll make sure that every business object in your ASP.NET webapplication originates from the same ObjectContext instance. In this way, you won’t have to worry about which object is being tracked by which ObjectContext, and you can easily exchange business objects (i.e. entities) between all of your BLL classes. Since the ObjectContext instance has the lifespan of only one HTTP request, it’s also relatively short lived.

Note:

Be wary of any asynchronous operations that may occur within your ASP.NET application, when using a globally shared ObjectContext instance. Two or more threads simultaneously trying to update data using the same ObjectContext instance can cause serious problems.

One ObjectContext instance per business transaction

This is the last method of managing an ObjectContext lifespan that I’ll be discussing in this article. Using this method we will be creating and using one instance of an ObjectContext class within the scope of a business transaction. After the business transaction is complete, we will save all changes to the underlying data store and then dispose the ObjectContext instance.

By a business transaction I mean a series of operations that atomically belong together. For example: in a webshop application, if we want to store an order in our system, we would first have to create an Order object. Next we would convert the contents of the shopping cart into Orderline objects. These Orderline objects would then have to be added to the Order object. Only after these steps are complete, we can safely store the complete Order object to the database. By using the Entity Framework in such business transactions, changes should be tracked by one single instance of an ObjectContext class. Doing so we are actually applying the “Unit of Work” pattern.

Sharing an ObjectContext within the scope of a business transaction is a trivial task in an ASP.NET application that doesn’t make use of BLL classes. However, in applications that do have a middle layer things become a little bit harder. We need to somehow “connect” the BLL instances within the scope, so they can all use the same ObjectContext instance. This is best done using some sort of helper object, which would contain the ObjectContext instance, and thus defining the scope. We could then for example create an “AddToScope” method on the helper object, which would be responsible for placing the BLL instances into scope. However, there is a more elegant and transparent construction possible. By mimicking part of the behavior of the .NET Framework’s TransactionScope class, we could make our BLL classes self-aware of the scope they currently belong to.

In the sample code below, an instance of the custom UnitOfWorkScope class in conjunction with a (C#) “using” statement is responsible for defining the ObjectContext scope. All BLL instances created within scope can automatically detect it, and therefore use the same ObjectContext instance.

Listing 3: Defining the scope of a business transaction

/* Create a new ObjectContext scope, in which all BLL (middle layer) objects share
 * the same ObjectContext instance: */
using (new UnitOfWorkScope(true)) /* "true" flag indicates that all changes
                                   * should be saved at the end of the scope. */
{
    /* The OrderBLL class can automatically detect the current scope: */
    OrderBLL orderBLL = new OrderBLL();
    /* The OrderlineBLL class can automatically detect the current scope: */
    OrderlineBLL orderlineBLL = new OrderlineBLL();
    /* The ProductBLL class can automatically detect the current scope: */
    ProductBLL productBLL = new ProductBLL();
    /* Create a new order: */
    Order newOrder = new Order();
    newOrder.FirstName = "Jordan";
    newOrder.LastName = "van Gogh";
    // .. add more order properties here ...
    /* Make sure the newOrder object will be added to the data store: */
    orderBLL.Add(newOrder);
    /* Convert the ShoppingCartItem objects into Orderline objects: */
    foreach (ShoppingCartItem cartItem in _shoppingCart.Items)
    {
        Orderline newLine = new Orderline();
        /* Retrieve a Product object based on its PK: */
        Product product = productBLL.GetProductByID( cartItem.ProductID );
        /* We should be able to define a relationship between the 
         * newLine object and the product object since we are currently 
         * in a "Unit of Work" scope, in which both orderlineBLL and 
         * productBLL objects share the same ObjectContext instance: */
        newLine.Product = product;
        newLine.Quantity = cartItem.Quantity;
        /* Make sure the orderline object will be added to the data store: */
        orderlineBLL.Add(newLine);
        /* Define a relationship between the newLine and the newOrder objects: */
        newOrder.Orderlines.Add(newLine);
    }
} /* End of scope. The newOrder object and it's Orderline objects will 
   * now be persisted to the underlying data store. */

After studying the code sample above, those who aren’t familiar with the TransactionScope class may be wondering how the BLL objects can automatically detect the current scope, just by placing them in a “using” construct. Well, this is actually achieved by using a thread static class member. Values of thread static class members are only bound to the current thread, instead of the entire application as is the case with normal static members. Besides their scope, they act in the same way as normal static members. In .NET we can make a static class member thread static by adding a [ThreadStatic] attribute to it.

The UnitOfWorkScope class encapsulates an ObjectContext instance. By setting the value of a thread static member to a UnitOfWorkScope instance, we have a way of sharing its encapsulated ObjectContext among our BLL objects within the current thread. It’s almost similar to sharing and using a global static ObjectContext, except this time it’s only being shared within the current thread.

Listing 4: The UnitOfWorkScope class implementation

/// <summary>
/// Defines a scope wherein only one ObjectContext instance is created, 
/// and shared by all of those who use it. Instances of this class are 
/// supposed to be used in a using() statement.
/// </summary>
public sealed class UnitOfWorkScope : IDisposable
{
    [ThreadStatic]
    private static UnitOfWorkScope _currentScope;
    private NorthwindObjectContext _objectContext;
    private bool _isDisposed, _saveAllChangesAtEndOfScope;
    /// <summary>
    /// Gets or sets a boolean value that indicates whether to automatically save 
    /// all object changes at end of the scope.
    /// </summary>
    public bool SaveAllChangesAtEndOfScope
    {
        get { return _saveAllChangesAtEndOfScope; }
        set { _saveAllChangesAtEndOfScope = value; }
    }
    /// <summary>
    /// Returns a reference to the NorthwindObjectContext that is created 
    /// for the current scope. If no scope currently exists, null is returned.
    /// </summary>
    internal static NorthwindObjectContext CurrentObjectContext
    {
        get { return _currentScope != null ? _currentScope._objectContext : null; }
    }
    /// <summary>
    /// Default constructor. Object changes are not automatically saved 
    /// at the end of the scope.
    /// </summary>
    public UnitOfWorkScope()
        : this(false)
    { }
    /// <summary>
    /// Parameterized constructor.
    /// </summary>
    /// <param name="saveAllChangesAtEndOfScope">
    /// A boolean value that indicates whether to automatically save 
    /// all object changes at end of the scope.
    /// </param>
    public UnitOfWorkScope(bool saveAllChangesAtEndOfScope)
    {
        if (_currentScope != null && !_currentScope._isDisposed)
            throw new InvalidOperationException("ObjectContextScope instances " +
                                                "cannot be nested.");
        _saveAllChangesAtEndOfScope = saveAllChangesAtEndOfScope;
        /* Create a new ObjectContext instance: */
        _objectContext = new NorthwindObjectContext();
        _isDisposed = false;
        Thread.BeginThreadAffinity();
        /* Set the current scope to this UnitOfWorkScope object: */
        _currentScope = this;
    }
    /// <summary>
    /// Called on the end of the scope. Disposes the NorthwindObjectContext.
    /// </summary>
    public void Dispose()
    {
        if (!_isDisposed)
        {
            /* End of scope, so clear the thread static 
             * _currentScope member: */
            _currentScope = null;
            Thread.EndThreadAffinity(); 
            if (_saveAllChangesAtEndOfScope)
                _objectContext.SaveChanges();
            /* Dispose the scoped ObjectContext instance: */
            _objectContext.Dispose();
            _isDisposed = true;
        }
    }
}

The UnitOfWorkScope class should only be used in a “using” construct. At the start of the construct a new UnitOfWorkScope instance is created. The constructor of this class creates a new ObjectContext instance. This ObjectContext is then shared and used by other BLL objects within the “using” construct. At the end of the construct the Dispose method of the UnitOfWorkScope object is automatically called, which in turn disposes the encapsulated ObjectContext instance.

In our BLL classes we can use the internal static CurrentObjectContext property to get a reference of the ObjectContext instance that’s bound the current scope. We could for example define a ObjectContext property within these classes, as in the code sample below:

Listing 5: Using the CurrentObjectContext property of the UnitOfWorkScope class

private NorthwindObjectContext _objectContext;
/// <summary>
/// Returns the ObjectContext instance that belongs to the 
/// current UnitOfWorkScope. If currently no UnitOfWorkScope
/// exists, a local instance of the NorthwindObjectContext class
/// is returned.
/// </summary>
protected NorthwindObjectContext ObjectContext
{
    get
    {
        if (UnitOfWorkScope.CurrentObjectContext != null)
            return UnitOfWorkScope.CurrentObjectContext;
        else
        {
            if (_objectContext == null)
                _objectContext = new NorthwindObjectContext();
            return _objectContext;
        }
    }
}

Using one “fresh” ObjectContext instance per business transaction, is generally considered to be a good practice. And by using the techniques I demonstrated in this section, you can also make sure that it’s properly disposed when it’s no longer needed.

Note:

Using thread static class members in a wider scope than in the specified “using” construct can result in unpredictable behavior. This is because ASP.NET threads might be re-used, and thus if there are any leftover thread static values, they might also be unknowingly used again.

Sample Application

To demonstrate the techniques that I’ve described in this article I've created a small sample application, based on a part of the Northwind database. It also includes a small ready-to-use generic ObjectContext management framework. As you may see in the screenshot of the VS solution explorer below, I've created a 3-layered ASP.NET application.

The solution consists of 5 projects. I will give a brief overview of the functions of each of the projects, and how they relate to one another. I won't go into too much detail, since this article is about managing ObjectContext lifespan and scope, and not about n-layered design in general.

Note:

The code samples that I’ve presented in the previous sections of this article, are loosely based on the code in the sample project. However, they have been simplified to avoid confusion. So you may find that although some classes share the same name as classes used in the previous code samples, they may have different implementations.

Northwind.DataLayer.Model

This project represents the Data Access Layer (DAL) of the application. It contains its main data access component, in the form of an ObjectContext. Since I chose to generate a model directly from database, the business objects (i.e. domain entities) are also contained in this project. I've have selected two tables from the Northwind database - Categories and Products - to be included in my model. This means we have two business objects: Categories and Products.

Note:

As you may see, the names of the business objects are plural. This is because all the tables in the Northwind database are named plural.

Northwind.BusinessLayer.Facade

This project represents the Business Logic Layer (BLL): the core of the application. In here we will store most of the LINQ-to-Entities queries. Although nowadays it’s easy to use an Entity Data Model directly in the Presentation Layer, it offers many benefits to isolate and centralize your LINQ-to-Entities queries, business validation rules, and other business logic in a separate project. For instance it can dramatically improve the maintainability and extensibility of your application. Another big advantage is that it will also enable you to unit test your queries and logic.

I've chosen to name this project Façade, because it only acts as a gateway for the ObjectContext class of the DAL. It contains some business validation rules, but in this case it doesn't contain any real business logic. In larger - real life - solutions, I usually add another project to my Business Layer called BusinessLogic to store any real business logic that may exist (in this case that would have resulted in a Northwind.BusinessLayer.BusinessLogic project). A Façade project would then provide a simplified interface to the classes contained in that project.

The class diagram of the Façade project:

The FacadeBase class is the generic base class for the other Façade classes. It offers some virtual generic methods to provide a consistent interface for derived classes. I've included a separate derived Façade class for each of the business objects. These classes provide an interface for the Presentation Layer to work with. The Presentation Layer is not allowed to use an ObjectContext directly, so every business object/entity operation must be done using the Façade classes.

Then there is also the UnitOfWorkScope class, which in this sample application is derived from the generic ObjectContextScope class of the Framework project. The function of this class has already been discussed in the previous section.

Northwind.BusinessLayer.Facade.Tests

This is the unit testing project. It contains some unit tests for the Façade project (the BLL). I've only included a few partial tests for demonstration purposes only.

Northwind.Framework.ObjectContextManagement

Classes contained within this project manage ObjectContext instantiation and scope. It's a generic framework, so it can be easily integrated in other projects too.

The class diagram of this project:

The generic ObjectContextManager classes manage ObjectContext instantiation and scope for the Business Logic Layer classes of the application (in this case the Façade classes). Each derived ObjectContextManager class handles instantiation and scope in its own distinct way.

AspNetObjectContextManager: This manager class can only be used in an ASP.NET application. Provides one (and only one) ObjectContext instance for the lifespan of one HTTP request. This instance is then shared by all BLL/Facade classes who make use of it. It also comes with a HttpModule - the AspNetObjectContextDisposalModule class - that automatically handles the disposal of the shared ObjectContext instance at the end of the HTTP request.
StaticObjectContextManager: Provides one static ObjectContext instance for the lifespan of the AppDomain. All BLL/Facade classes who use this class, will share the same ObjectContext instance. This can be useful in small Console applications or maybe unit testing projects, however you shouldn't use it in your ASP.NET websites and webapplications. I have earlier explained why.
ScopedObjectContextManager: This manager class allows you to define your own ObjectContext scopes. Scopes are defined by creating an instance of an ObjectContextScope class in a (C#) "using" construct. An ObjectContext scope maintains only one instance of an ObjectContext class. BLL/Facade objects created within the "using" construct (and thus within scope) can then automatically detect the current scope through an encapsulated ScopedObjectContextManager instance. All of those BLL/Facade objects will then automatically use and share the ObjectContext instance that’s bound to the current scope. At the end of the scope this ObjectContext instance is also automatically disposed.

Managing ObjectContext instantiation

The Visual Studio solution of a typical n-layered ASP.NET application is likely to include more than one project that references the BLL project of the solution. If you look at the sample application, besides the website project in the Presentation Layer, the Northwind.Facade.Tests project also makes use of the BLL/Façade classes. If for example you want your website to use a globally shared ObjectContext instance per HTTP request and you integrate this technique in your BLL/Façade classes, you would be unable to use these classes in your Tests project, since the Tests project does not run in a http context and is therefore unable to use the HttpContext.Current.Items property. A way to overcome such problems is to move to the process of ObjectContext instantiation out of your BLL/Façade classes, and to put it in a separate class. You would create a separate class for each technique that you want to be able to use in your application. Your BLL/Façade classes should then use an instance of one of these classes based on application configuration.

In the sample application I’ve provided a small generic framework for managing ObjectContext instantiation and scope within your BLL/Façade classes. It consists of an abstract base class called ObjectContextManager, and three derived classes called AspNetObjectContextManager, StaticObjectContextManager and ScopedObjectContextManager. The behavior of each of these classes have been described in the previous section of this article. The Façade (BLL) classes are able to instantiate one of these classes based on application configuration.

For example, the Web.config file of the website contains the following configuration:

<configSections>  
    <section name="Northwind.BusinessLayer.Facade.ObjectContext"
           type="System.Configuration.SingleTagSectionHandler"/>
</configSections>
<Northwind.BusinessLayer.Facade.ObjectContext
managerType="Northwind.Framework.ObjectContextManagement.AspNetObjectContextManager"/>

Based on these configuration settings, the Façade/BLL classes will use one globally shared ObjectContext per HTTP request.

The Northwind.BusinessLayer.Facade.Tests project on the other hand, has a slightly different configuration:

<configSections>
  <section name="Northwind.BusinessLayer.Facade.ObjectContext"
           type="System.Configuration.SingleTagSectionHandler"/>
</configSections>
<Northwind.BusinessLayer.Facade.ObjectContext
 managerType="Northwind.Framework.ObjectContextManagement.ScopedObjectContextManager"
 />  

With these configuration settings, the Façade/BLL classes will use one single ObjectContext per business transaction.

Using these ObjectContextManager classes for managing ObjectContext instances, will make your BLL more adaptable. If for example you ever to need to create a new project based on a brand new Presentation Layer technology, you only need to derive a new ObjectContextManager class, and configure your BLL to use it.

Figure 5: The relationship between the Façade classes and the generic ObjectContextManager classes

The relationship between the Façade classes and the generic ObjectContextManager classes

In this article I’ve described a few methods of managing ObjectContext lifespan and scope in a n-layered ASP.NET application. Each of these methods works in its own distinct way. We have seen how to use one globally shared ObjectContext per HTTP request, and we have also seen how to share one ObjectContext between multiple middle layer objects in a business transaction.

It’s important to understand that this is just my take on the matter. There might be several better ways of accomplishing the same tasks, that I haven’t figured out yet. So keep on reading!

<< Previous Article

Continue reading and see our next or previous articles

Next Article >>

About Jordan Van Gogh

Sorry, no bio is available

View complete profile here.

You might also be interested in the following related blog posts

DLinq: Mapping a Database to a DataContext class. read more
DLinq: Playing with knives. read more
Get The Most Out Of Your Format String read more
Talking Points: ADO.NET Entity Framework read more
Sneak Peek at the EntityDataSource Control read more
EF: GetRelationTypeExpensiveWay read more
Exploring EntityKeys, Web Services and Serialization a little further read more

Top

Discussion

Subject	Author	Date
Update pattern for N-tier ASP.NET Applications	Buddhima W.Wickramasinghe	5/11/2009 12:34 AM
Hi Jordan, Thanks for the great article. The pattern you have introduced in the article has helped me to resolve lot of concerns which I had with the EF in n-tier scenario. Only thing missing in the sample was the update method. It would be really great if you can update your sample with best implementation of “update method” for N-tier ASP.NET application scenario”. Best Regards Buddhi.. Reply \| Permanent link
RE: Update pattern for N-tier ASP.NET Applications	Buddhima W.Wickramasinghe	5/11/2009 1:50 AM
Hi jordan, I think I missed somethingon my last post. I really like to know the best approach for the object graphsand concurrency handling in update scenarios Buddhi Reply \| Permanent link
RE: RE: Update pattern for N-tier ASP.NET Applications	Jordan Van Gogh	5/12/2009 5:38 PM
Hi Buddhi, By default the ObjectContext will save changes to the database without checking for concurrency. This works fine for me in most of my projects. However, if you wish to handle concurrency properly, you can set the concurrencymode of entity properties to "fixed" to enable checking for concurrency. Next you would have to handle OptimisticConcurrencyExceptions somewhere in your code. (General info about handling concurrency in EF can be found here: http://msdn.microsoft.com/en-us/library/bb399228.aspx). In a setup like the sample project (ie 3 layers), you have two options: * Handle concurrency issues in your presentation layer: This gives you the most flexibility. You can make different decisions regadering concurrency depending on the situation. However, you'll have to write custom concurrency handling logic for every update transaction. Even for (almost) similar transactions. * Handle concurrency issues in your business layer (BLL/Facade): You'll have to move your update transactions into your business layer (which is actually not a bad practice ;). You would for exampe create methods like UpdateOrderStatus() and UpdateWebsiteVisitCount(). These methods would then contain their own concurrency handling logic, instead of leaving it up to the presentation layer code. It's a good way of keeping your presentation layer code clean and simple. Imho there is no "best way" of handling concurrency . I recommend choosing one of the options mentioned above, and then using it consistently. Regards, Jordan. Reply \| Permanent link
How to Use Different Connection Strings	Chris Etl	5/14/2009 3:36 PM
How can I modify the code to use a connection string other than what is saved in web.config to instantiate the ObjectContext? I need to either pass in the connection string from somewhere, or pull it out of a session variable or something, but I'm not sure how to modify the framework code to not use the default constructor. Your help would be appreciated. Reply \| Permanent link
RE: How to Use Different Connection Strings	Chris Etl	6/30/2009 12:50 PM
Does anyone know how to do this? I have been waiting for quite a while and really would like to be able to use this pattern for this. I need to connect to several different databases programmatically (one at a time). I have it working wonderfully in other solutions where I can use the connection string right in the web.config file. Reply \| Permanent link
RE: RE: How to Use Different Connection Strings	Jordan Van Gogh	7/2/2009 6:00 PM
Hi Chris, It's not possible to change the connection string of an objectcontext after the first connection to the database has been made. The only way to use another connectionstring is to create a new instance of the objectcontext. However, as you probably know, you can't "mix" entities between the old and the new instance, without detaching and attaching the entities first. If this isn't a problem for you, I can show you which modifications you need to make to the framework. Just let me know. Regards, Jordan. Reply \| Permanent link
RE: RE: RE: How to Use Different Connection Strings	Chris Etl	7/23/2009 4:03 PM
Yes, I need to use completely different instances of the ObjectContext to connect to different databases (one at a time) which have the same schema. I would love to see what changes you recommend for this. I have been unable to figure it out on my own (I'm pretty new to using the entity data models). I have connection strings stored in another database and have them available to me at the time that I need to instantiate an ObjectContext. I just can't figure out how to "pass" the conn. string to where it's instantiating it. All help is appreciated as I am needing this right now! Reply \| Permanent link
RE: How to Use Different Connection Strings	Bob V	2/2/2011 4:04 PM
I also need to modify the connection string on the fly. I am currently trying to implement merge the code from another project that does this with a SqlConnectionStringBuilder object, but I can't see where to include that in this solution. Any help would be appreciated. Reply \| Permanent link
Updating objects in facade classes	John Hoffman	7/22/2009 1:03 PM
How would an update occur? I would imagine the UI layer(web page) would like to get EntityObjects from the Facade Layer (BLL), then get/set properties after the user makes come changes, and then turn around and call Facade.UpdateXXXX(EntityObject eo). In this scenario would the Facade method make use of the UnitOfworkScope ? Do you have to attach the incoming EnittyObject to the Facades ObjectContext ? Are the EntityObjects detached when returned from the Facade layer methods like GetProducts()? BTW: Thanks for the article, it was thorough yet concise. Reply \| Permanent link
RE: Updating objects in facade classes	Jordan Van Gogh	7/29/2009 5:25 PM
Hi John, No, in the project setup (ie app. architecture) as described in this article, the entity objects are not detached when returned from the Getxxx methods. The whole point of the article was to demonstrate how to use a single shared ObjectContext instance between multiple BLL/Service Layer/Facade Layer classes. By using a single ObjectContext instance, you don't have to attach/detach entites, because all of them orginate from the same ObjectContext. Also we don't add separate Updatexxx methods on the BLL/Service Layer/Facade Layer classes. We have a single SaveAllObjectChanges() method, which updates all modfied entities. If you want to add validation logic, you can use the ObjectStateManager property of the ObjectContext to find updated/modified entities (and to validate those of course ;). Regards, Jordan. Reply \| Permanent link
RE: RE: Updating objects in facade classes	Feodor Tsu	8/12/2009 10:29 AM
Hi Jordan, >...we don't add separate Updatexxx methods on the BLL/Service Layer/Facade Layer classes. We have a single SaveAllObjectChanges() method, which updates all modfied entities what does it means ? I can't use ObjectDataSource with Update method and DataObjectTypeName ? Because the entity object is the same and entity object class does not has default constructor without params ? And so I cant use editable controls linked to this ObjectDataSource ? Reply \| Permanent link
"Be wary of any asynchronous operations"	Herb Raffaele	7/29/2009 8:19 PM
Great article Jordan! In the shared ObjectContext per Http request example, you mention that we should "Be wary of any asynchronous operations". Do you mean that this is not a good option for websites that use AJAX? Have you thought of ways to deal with asyncrhonous operations? Reply \| Permanent link
Error	Andy Diep	8/31/2009 4:32 PM
Jordan Thank you for sharing your knowledge. It's awsome article. I am trying to use the my local sql express database connectionString="Data Source=.\sqlexpress;Initial Catalog=Northwind;Integrated Security=True" Stack trace Exception ServerVersion = '((System.Data.EntityClient.EntityConnection)((System.Data.Objects.ObjectContext)(this.ObjectContext)).Connection).ServerVersion' threw an exception of type 'System.InvalidOperationException' Any suggestion? Andy Reply \| Permanent link
Memory Editing	Juvil John Soriano	9/16/2009 5:38 AM
Hi Jordan, Great article. I need to clarify though, in an n-tier architecture where the BL classes is a type List<Entity> how will this affect your Entities inside the BL during Update/Edit? it might not be that clear but let me sight you an example. i've got a class, lets say. public class Items : List<Item> { ItemEntities _DAL; public Items() { _DAL = new ItemEntities(); } public void Get() { this.addrange(_DAL.Item.ToList()); } public void Save() { _DAL.SaveChanges(); } } now in your presentation layer you have this. private Items _items; protected void Page_Load(object sender, EventArgs e) { _items = new Items(); if(!isPostBack) { _items.Get(); <--- Fill the collection Session["Items"] = _items; } else _items = (Items)Session["Items"]; } protected void button1_click(object sender, EventArgs e) { //Sample update to the first record, In Memory Editing. Item _item = _items.First(); _item.Name = "Hello World!"; } protected void button2_click(object sender, EventArgs e) { _item.Save(); } do you have any idea now where is this going? I guess my question is that how will this fit in your solutions? Reply \| Permanent link
RE: Memory Editing	Tanveer Khan	11/2/2009 12:02 AM
Hi Juvil, Have you got the solution of Updating List<Entity> into the given scenario. Hi Jordan, it's a great article. We shall be very thankful if you provide the Update scenario in the sample application. As of others, I'm too confused with memory editing of entity objects. Regards, Tanveer. Reply \| Permanent link
Only support ObjectContext's Default Constructor	Naeem Hassan	2/11/2010 2:08 PM
Hi, A great job but I have following issue. How can I instantiate ObjectContext instance in ObjectContextManager derived class instead of default constructor. e.g. in ScopedObjectContextManager class _objectContext = new T(); it only able to construct instance from default constructor. But I need to call other constructor. Thanks New in Linq Reply \| Permanent link
RE: Only support ObjectContext's Default Constructor	Naeem Hassan	2/16/2010 9:18 AM
I solved it. Replace //_objectContext = new T(); EntityConnection connection = new EntityConnetion(); ... set all required variables and construct as follow ... ... _objectContext = Activator.CreateInstance(typeof(T), Connection) as T; Thanks Reply \| Permanent link
Design flaw in UnitOfWorkScope	Steven	3/9/2010 4:10 AM
There is a design flaw in the UnitOfWorkScope class. The dispose method should never call _objectContext.SaveChanges(). This is because the dispose method will always be called even when the code threw an exception. In that case it would be very bad to persist the changes to the database, but this is what will happen. For this same reason .NET's TransactionScope contains a Complete() method. Consider adding a Commit(), Submit() or Complete() method to the UnitOfWorkScope class and call _objectContext.SaveChanges() from there. In the Dispose method you should do nothing more than just calling _objectContext.Dispose(). Reply \| Permanent link
How to update data?	Sergey Trukshan	3/31/2010 5:52 AM
Hi, thank you for source codes. I'm using this codes and can retrieve data, but can't update, insert or delete it. The main reason is than object.EntityKey being lost when I'm trying to submit changes. I'm using the DomainService to communicate with SL application. DomainServer methods calls Facade classes methods. In xaml I'm using DomainDataSource and DataForm controls. When I retrieve data I can see EntityKey values are valid, but when I call DomainDataSource controls SubmitChanges method and I put brekpoint in DOmainService class update method I can see that EntityKey value is null. Maybe I do something wrong? Reply \| Permanent link
Implementing with POCO Self Tracking Entities	Dev Dnlds	4/27/2010 10:09 AM
Hi Van, Thanks for such a great article. I am implementing the same with EF4.0 and even for this version everything is working fine without any build errors. However if I generate the entities through POCO self tracking template, the entities modified properties are are not getting reflected into the database. It is simply executing the SaveChanges method without any end result. If I go with the same code (not even a single code modification) along with the default edmx and the auto generated edmx.cs files, everything is running fine. It would be great if I can get any assistance on this. Thanks in advance Regards KK Reply \| Permanent link
ObjectContext and mutithreading	Nourredine Salah-Mansour	11/20/2010 9:20 AM
Thank you for your article. I downloaded your sample code and I am thinking if i can use it in a murltiThread WCF applicaton with concrrency. In MSDN , it says : The ObjectContext class is not thread safe. The integrity of data objects in an ObjectContext cannot be ensured in multi-threaded scenarios. So, I would like your opinion. nordine. Best regards Reply \| Permanent link
WCF and ObjectContext	Nourredine Salah-Mansour	11/20/2010 5:21 PM
Thank you for your article . l dowloaded the code sample and i am thinking using it in a WCF multithread application with data concurrency. In MSDN , it 's says : The ObjectContext class is not thread safe. The integrity of data objects in an ObjectContext cannot be ensured in multi-threaded scenarios. can i have your opinion. Reply \| Permanent link
The object cannot be deleted because it was not found in the ObjectStateManager.	Fanis P	11/21/2010 1:45 PM
Great job, thanks for this. the problem I am facing is that I can't delete an object, I am getting the following error The object cannot be deleted because it was not found in the ObjectStateManager. The code I am using is the following using (new UnitOfWork(true)) { ExcProducts excProducts = excProductsDAO.getExcProduct(excProdid); excProductsDAO.Delete(excProducts); excProductsDAO.SaveAllObjectChanges(); } The exception raised in Delete method I have a Product object which it has ExcProducts. I am trying to remove an item from ExcProducts List which is part of an object. Thanks for any help Reply \| Permanent link
The object cannot be deleted because it was not found in the ObjectStateManager.	Fanis P	11/21/2010 1:49 PM
Great article!!! I have a problem and I need some help here. I have an object Products which it has a property ExcProduct as List. I am trying to remove an object from ExcProduct list and I am getting the following error The object cannot be deleted because it was not found in the ObjectStateManager. The code I am using is the following using (new UnitOfWork(true)) { ExcProducts excProducts = excProductsDAO.getExcProduct(excProdid); excProductsDAO.Delete(excProducts); excProductsDAO.SaveAllObjectChanges(); } the exception raised in Delete method Thanks for any help Reply \| Permanent link
use objectContext EF model	Azeddine R,	12/2/2010 9:03 AM
Than you for this article. it's really a good job. i Want to use objectContext of entity framework model. like: using (this.objectContext = new CommunicationEntities()) where objectContext is public property. How can i modify the project to use my objectContext to add somme entities in association or inheritance without attaching and detaching objects? Reply \| Permanent link
EF 4.1 ObjectContext	Nea Plus	6/7/2011 4:12 PM
Hi, first thanks for your really good article. I have got a question about EF 4.1 CTP 5, since new ObjectContext internally implements several patterns including Identity Map and Unit of Work.. do i need use your classes, or dbset classes already did what yours do? ty. Reply \| Permanent link
RE: EF 4.1 ObjectContext	Jordan Van Gogh	6/8/2011 8:59 AM
Hi Nea, I personally switched to using NHibernate+Spring, which support these kind of features out of the box, and is arguably a more mature ORM product than EF. However, for EF4.+ in a n-tier scenario you could consider using the (relatively) new self tracking entities. Otherwise I think you'll still need to create some supporting classes like the AspNetObjectContextManager sample class which was mentioned in this article. You can ofcourse modify the sample code of this article to support the new DbContext classes in addition to the traditional ObjectContext classes. Regards, Jordan. Reply \| Permanent link
EF 4.1	Jordan Van Gogh	6/8/2011 8:58 AM
Hi Nea, I personally switched to using NHibernate+Spring, which support these kind of features out of the box, and is arguably a more mature ORM product than EF. However, for EF4.+ in a n-tier scenario you could consider using the (relatively) new self tracking entities. Otherwise I think you'll still need to create some supporting classes like the AspNetObjectContextManager sample class which was mentioned in this article. You can (ofcourse) modify the sample code of this article to support the new DbContext classes in addition to the traditional ObjectContext classes. Regards, Jordan. Reply \| Permanent link
EF 4.2 Code First	R W	11/23/2011 7:32 PM
I know this article is old but is there any way it could be redone to work with EF 4.2 Code First DbContext? I'd be eternally grateful if at all possible (my own attempts came unstuck as I don't know how to work with an EntityObject equivalent when declaring the facade). Reply \| Permanent link
ss	Sudhir Dutta	12/24/2008 3:49 AM
sdd Reply \| Permanent link
Use of ThreadStatic attribute	Daniel Robinson	1/2/2009 5:50 PM
Hi Jordan, Thanks for the great article! :-) I would like to suggest that perhaps ThreadStatic could be avoided in your example by the use of System.Web.HttpContext.Current.Items. Here's a link to Scott Hanselman's blog about the subject: http://www.hanselman.com/blog/ATaleOfTwoTechniquesTheThreadStaticAttributeAndSystemWebHttpContextCurrentItems.aspx Regards, Daniel. Reply \| Permanent link
RE: Use of ThreadStatic attribute	Jordan Van Gogh	1/5/2009 4:53 AM
Hi Daniel, Thanks for your feedback ! As you may have read, I've discussed multiple techniques of dealing with ObjectContext scopes. One of them makes use of the HttpContext.Current.Items hashtable, as you suggested. The only real limitation of this property, is that you can only use it in a HTTP context. This means for example that you will not be able to use it in your unit testing project(s). And I'm a big fan of unit testing my BLL classes ;) I've only used the ThreadStatic attribute in the UnitOfWorkScope (or ObjectContextScope in sample project) class. This class is only to be used in a "using" construct, and not as a page or application variable. In such a limited scope, ThreadStatic values can still be used without problems. Best regards, Jordan. Reply \| Permanent link
Good Job	Antonio Castro Jr	1/29/2009 8:41 AM
Congratulations Jordan, you did a really good job. It is just what I have been looking for. I would like to ask you permission to translate your article to Portuguese to help the guys here in Brazil. May I? Thanks Reply \| Permanent link
RE: Good Job	Jordan Van Gogh	1/29/2009 3:01 PM
Hi Antonio, I'm glad you liked it. You can certainly translate the article to Portuguese if you like to. If you are going to use/repost the sample code, please add a correction to the Northwind.Framework.ObjectContextManagement.ObjectContextScope class. Shortly after posting the article I realised that line 81 to 84 should have been wrapped within a try/catch/finally statement, like such: try { if (_saveAllChangesAtEndOfScope) _objectContext.SaveChanges(); } catch( Exception e ) { throw e; } finally { _objectContext.Dispose(); _isDisposed = true; } Best regards, Jordan. Reply \| Permanent link
RE: RE: Good Job	Antonio Castro Jr	1/30/2009 7:24 AM
Thanks Jordan, Have you thought about the multiple objectcontexts cenario ? I think it could be acomplished using TransactionScope. Any ideas? [] Reply \| Permanent link
RE: RE: RE: Good Job	Jordan Van Gogh	2/6/2009 9:50 AM
Hi Antonio, Sorry for my late reply, been really busy this week.. What exactly do you mean by a multiple ObjectContexts scenario ? Isn't this something what the ObjectContextScope/UnitOfWorkScope classes from the sample project are able to solve ? Regards, Jordan. Reply \| Permanent link
Multiple ObjectContexts	Tim Tompkins	4/7/2009 10:57 AM
Jordan, I'd like to pick up on the multiple ObjectContexts question one of the earlier commentors mentioned. (excellent article btw). I'm on my first EF project & have a scenario where there are several models each with their own ObjectContext / connection string. I.e. like having a NorthWindContext and an AdventureWorksContext. What I'm now trying to acheive is transactions that traverse the two contexts. I believe I can do this using TransactionScope but am interested in whether I can leverage UnitOfWorkScope. The reason behind that is that UnitOfWorkScope centralizes all the SaveChanges which is handy for centralizing exception handling etc. You seemed to suggest in an earlier response that ObjectContextScope/UnitOfWorkScope could resolve the multiple context issue - but I can't see how. Can you eloborate please? Reply \| Permanent link
RE: Multiple ObjectContexts	Jordan Van Gogh	4/8/2009 4:52 AM
Hi Tim, In earlier response I didn't understand the question about multiple objectcontexts. I thought the commentor was talking about multiple objectcontext instances, but now I understand he was talking about multiple objectcontext types. A big difference ofcourse ;) The original sample does not support multiple ObjectContext types. However, I have been playing around with sample code last night, and I managed to get it working. I made a lot of changes to the code, so I've decided to just put the updated sample code for download: http://sites.google.com/a/jordanvangogh.nl/code/Home/northwind_multi_oc.zip Somes of changes include the following: * Added a second entitymodel to the Model project (Employees). * Added a EmployeesFacade class to the Facade project. * Added a SaveAllChanges() method to the ObjectContextScope class. You can test the updated code using the AddTest() test method of the ProductsFacadeTest class of the Facade.Tests project. Please have a look, and let me know what you think. Regards, Jordan. Reply \| Permanent link
RE: RE: Multiple ObjectContexts	Henry Wu	11/21/2009 2:40 AM
Hi Jordan, In the new source code at http://sites.google.com/a/jordanvangogh.nl/code/Home/northwind_multi_oc.zip I noticed that the class AspNetObjectContextManager.cs is not in the project anymore and that the web.config is now using ScopedObjectContextManager instead of AspNetObjectContextManager (as used in the old project). Just wondering the reasons for this change. Hope you can help clarify. Thanks! Henry Reply \| Permanent link
Question about Scope	Bala Chen	2/18/2009 3:16 AM
Hi...Jordan, I have a question about using ObjectContext per Transaction. If exception happened in using block,it shouldn't SaveChange in Dispose. How can i know exception happen in using block,when the ObjectContextScope Dispose do you have any idea? using (new UnitOfWorkScope(true)){ Products newProduct = new Products(); productsFacade.Add(newProduct); ..... //Some exception here ..... Categories newCategory = new Categories(); categoriesFacade.Add(newCategory); } //if exception,still excute context.SaveChange() when dispose Reply \| Permanent link
RE: Question about Scope	Jordan Van Gogh	2/19/2009 9:46 AM
Hi Bala, Good question! In this case it's best not let the UnitOfWorkScope class automatically save the changes, but rather to do it "manually" yourself. You should wrap the using construct within a try/catch block. For example: try { using (new UnitOfWorkScope()) { ProductsFacade productsFacade = new ProductsFacade(); Products newProduct = new Products(); newProduct.ProductName = "New test Product"; newProduct.SupplierID = 1; CategoriesFacade categoriesFacade = new CategoriesFacade(); Categories category = categoriesFacade.GetCategoryByID(1); newProduct.Categories = category; productsFacade.Add(newProduct); /* "Manually" call SaveAllObjectChanges() at end of scope / productsFacade.SaveAllObjectChanges(); } } catch { / Dispose() on UnitOfWorkScope is still called! / / But object changes aren't saved. */ } Best regards, Jordan. Reply \| Permanent link
RE: RE: Question about Scope	Bala Chen	2/19/2009 11:58 AM
hi..Jordan, Thank you for your answer.I think this is a very good solution On the other hand ,I am curious about how do TransactionScope know to rollback when exception happened.such as using (TransactionScope ts = new TransactionScope()){ ..... //Exception here ..... ts.Complete(); //do commit } //do rollback when exception Actually,i am trying to do nesting UnitOfWorkScope,hus found that this problem. Anyway,thanks... Bala ^_^ Reply \| Permanent link
RE: RE: RE: Question about Scope	Bala Chen	2/20/2009 1:26 AM
hi..Jordan: I am trying use Marshal.GetExceptionCode() to catch exception. that's maybe work.. if (_saveAllChangesAtEndOfScope) { if(Marshal.GetExceptionCode() == 0) _objectContext.SaveChanges(); } Bala ^_^ Reply \| Permanent link
RE: RE: RE: RE: Question about Scope	Jordan Van Gogh	2/20/2009 3:56 AM
Hi Bala, I had a quick peek in the internals of the TransactionScope class, and it seems to be doing the following: - The "Complete()" method sets an internal boolean flag called "complete" to "true". If an exception would occur within the "using"-construct, the "Complete()" method wouldn't be called, and the "complete" flag would remain "false". - The "Dispose()" method of TransactionScope checks the value of the "complete" flag. If the value is "true", it will commit the transaction. If on the other hand the value is "false", it will rollback the transaction. So the TransactionScope instance itself doesn't seem to be aware of any exceptions that might have occured. The technique is simple, and could be easily integrateded in the UnitOfWorkScope class ;) Also, you mentioned to you would like to able to nest UnitOfWorkScope instances. I intentionally disabled this to keep the sample code simple. You would have to make some changes to the code to make this work. Regards, Jordan. Reply \| Permanent link
RE: RE: RE: RE: RE: Question about Scope	Bala Chen	2/23/2009 8:36 AM
Dear Jordan: thank you very much.. bala ^_^ Reply \| Permanent link
Facade	Brat R	3/6/2009 9:19 AM
Hey Jordan, I have been debating on how to use the Facade Pattern, Since it is supposed to be used to hide the logic of the business, should we really have multiple Facades since that would lead to the same businessManager classes. An other question would be since the Facade is supposed to interact with the Business Logic Layer, but the UnitofWork or transaction is in the Facade, would'nt the there be multiple calls to check the validity of each object, an simple example would be helpful. Reply \| Permanent link
RE: Facade	Jordan Van Gogh	3/11/2009 6:24 PM
Hi Brat, I think this is a matter of personal/preferred architectural style. It depends on how you design your solution, and what kind of code you put into your Facade and BusinessLogic projects. For example, I've created a webapplication for a manufacturing company that does not sell directly to private customers. However, they do want to provide productinformation to these potential customers, and be able to refer them to a dealer who sells their products. Selecting one or more dealers for a potential customer is done using a specific set of algorithms. I've put the classes that handle these algorithms in my BusinessLogic project. These classes are only used by the Facade classes (in the Facade project), and are "hidden" for the presentationlayer For instance, in my DealerFacade class I've included the following method: public List<Dealer> GetPreferredDealers( Product selectedProduct, string postalCode, int maxRangeInKm ) This Facade method provides a simplified interface for the presentationlayer to retrieve the best possible set of dealers based on some criteria. It internally makes use of multiple BusinessLogic classes (determing distance to customer, determing dealerpreference based on salesrecords etc.). Regards, Jordan.. Reply \| Permanent link
Client Server Question	Mahdi Shahidi	3/30/2009 1:28 AM
Hi Thanks for your good article I have got a question about "One ObjectContext instance per business transaction" I want to create a complex entity in client and pass it to the server to save that how can I create with "One ObjectContext instance per business transaction"? Best Regards Mahdi Reply \| Permanent link
RE: Client Server Question	Jordan Van Gogh	4/1/2009 5:59 PM
Hi Mahdi, I'm sorry, I do not fully understand your question. What kind of client and what kind of server do you mean? Best Regards, Jordan. Reply \| Permanent link

Please login to rate or to leave a comment.

Write once. Port to many.
The Intel AppUpSM developer program features SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell worldwide. Developer funding, rewards, and more. appdeveloper.intel.com/join

Check out the all-in-one .NET toolbox by Telerik:
AJAX, WinForms, Charts, Silverlight, WPF, ORM, Reporting, Web CMS, Testing.

Login

Lost Password?

Introduction

The problems of working with multiple ObjectContext instances

One shared static ObjectContext

Listing 1: Using a static ObjectContext

One shared ObjectContext instance per HTTP request

Listing 2: Using the HttpContext.Current.Items property

One ObjectContext instance per business transaction

Listing 3: Defining the scope of a business transaction

Listing 4: The UnitOfWorkScope class implementation

Listing 5: Using the CurrentObjectContext property of the UnitOfWorkScope class

Sample Application

Northwind.DataLayer.Model

Northwind.BusinessLayer.Facade

Northwind.BusinessLayer.Facade.Tests

Northwind.Framework.ObjectContextManagement

Managing ObjectContext instantiation

Figure 5: The relationship between the Façade classes and the generic ObjectContextManager classes

About Jordan Van Gogh

Other articles in this category

You might also be interested in the following related blog posts

Discussion