Is it possible to store ObjectContext on the client when using WCF and Entity Framework?

I have a WCF service which performs CRUD operation on my data model: Add, Get, Update and Delete. And I'm using Entity Framework for my data model. On the other side there is a client application which calls methods of the WCF service.

For example I have a Customer class:

[DataContract]
public class Customer
{
   public Guid CustomerId {get; set;}
   public string CustomerName {get; set;}
}

and WCF service def开发者_Python百科ines this method:

public void AddCustomer(Customer c)
{
    MyEntities _entities = new MyEntities();
    _entities.AddToCustomers(c);
    _entities.SaveChanges();
}

and the client application passes objects to the WCF service:

var customer = new Customer(){CustomerId = Guid.NewGuid, CustomerName="SomeName"};
MyService svc = new MyService();
svc.Add(customer); // or svc.Update(customer) for example

But when I need to pass a great amount of objects to the WCF it could be a perfomance issue because of I need to create ObjectContext each time when I'm doing Add(), Update(), Get() or Delete().

What I'm thinking on is to keep ObjectContext on the client and pass ObjectContext to the wcf methods as additional parameter.

Is it possible to create and keep ObjectContext on the client and don't recreate it for each operation? If it is not, how could speed up the passing of huge amount of data to the wcf service?

Sergey

No, the ObjectContext can't be serialised over a WCF service call.

The current version of the entity framework doesn't really have any support for n-tier apps like this.

We have an n-tier app using the entity framework and we detach our objects from the ObjectContext each time and do re-creation and re-attaching for every call and it works fine. There doesn't seem to be any significant performance cost for doing the recreations (SQL server will be pooling the database connections anyway), so unless you are doing something requiring really heavy throughput then don't get into premature optimisation. Just get it running, then profile it. To be honest, your biggest bottle neck is going to be the WCF service call and the data transfer over the network anyway, so if you are looking to improve performance, minimise the quantity of data you are transferring instead of worrying about your ObjectContext. Or you could create a service call that takes a list of objects and adds them all at the same time.

However, EF4 is going to do this better. Take a look at this MSDN article for some more information on n-tier support in EF4. If you work with the beta or wait a month for the release it might be worth taking a look.

The ObjectContext class in Entity Framework is designed around the concept of a Unit of Work. Its purpose is to track a number of changes made to data contained in the entity objects and then apply those changes as a batch to the underlying database (through the ObjectContext.SaveChanges method).
A unit of work has well-defined bounds and is designed to last during a limited period of time. In Entity Framework the unit of work is implemented through the ObjectContext this way:

using (var db = new ObjectContext()) // The unit of work starts with the constructor
{
    // perform work
} // The unit of work ends with the Dispose method

The ObjectContext is meant to be created and disposed ad-hoc whenever some work needs to be performed on the data in the database, therefore it's designed to be lightweight in this sense.

That being said, I don't believe that keeping a long-lived instance of the ObjectContext around will increase the application's performance. On the contrary, it will cause the ObjectContext instance to consume more memory as it continues tracking more operations.

If you need to transfer a large amount of data through a network, the best thing you can do is use a fast and lightweight communication protocol. In WCF you could use the netTcpBinding, which transfers binary-formatted messages through a TCP connection. It is important to remember that this only works if you are using .NET on both ends, since the binary format used is specific to .NET.

No, you can't keep ObjectContext at client (what is the matter to use WCF in this way ?), but you can implement delay changes saving on Service or create method AddCostumers(Customer[] customers)