Architecting Silverlight LOB applications (Part 3) – DomainServices and Repository

Hello again,

In the previous post I described an overview of an architecture that could be used when developing silverlight modular apps. In this post I’ll start with a simple business domain model and create a domain layer around that model.

In this example our app will be a web application for a company that sells products and that can be used by its customers to fulfill orders and its employees to process them. These orders have details which consist of products and quantities. Each product can have a product category. When a customer submits an order fulfillment, an employee of the company may process that order to prepare the items for shipping.

The company has a few departments, and each employee belongs to a department. This means that employees from the Sales department will be to process orders; employees from the Human Resources department will be able to recruit new employees; and employees from the Financial Department will be able to watch some charts and print reports with statistics of how sales are evolving as time goes by, sales reports, etc.

Continue reading

Managing the Entity Framework ObjectContext instance lifetime in WCF and sharing it among repositories

As I pointed out in a previous post about using the Repository pattern in EF and WCF, it’s a bad practice when service operations manage the ObjectContext instance lifetime and have dependencies on it.

In this post I’m going to show you how to share the same ObjectContext among repositories as long as the service is activated (either PerCall or PerSession) and have the service totally agnostic of it.

First lets introduce two concepts:

public interface IDbContext : IDisposable
{
    object Context { get; }
}

public interface IDbContextManager
{
    IDbContext GetDbContext();
}

The IDbContext interface can be used as a wrapper for the ObjectContext or even NHibernate’s ISession. The IDbContextManager will be used by the repositories to get an IDbContext instance.

To simplify things we can extend our existing ObjectContext class using a partial class that implements the IDbContext interface. In this case, since I’m using the same example as the previous post it should look like this:

public partial class MFEntitiesContainer : IDbContext
{
    public object Context
    {
        get { return this; }
    }
}


Lets see how the refactored EntityRepository class looks like:

public class EntityRepository<TEntity> : IRepository<TEntity>
    where TEntity : EntityObject, new()
{
    public EntityRepository(IDbContextManager manager)
    {
        this.SetContext(manager.GetDbContext());
    }

    private void SetContext(IDbContext ctx)
    {
        this.ObjectContext = ctx.Context as ObjectContext;
        this.FetchEntitySetName();
    }

    //.. same implementation as the previous post
}

So now we can use our repositories without having to worry how to give them an ObjectContext anymore. We simply have to supply an implementation of IDbContextManager. In this case, I’m going to implement a DbContextManager that will return the same IDbContext instance while the wcf service is activated in order to reuse it among repositories.

Continue reading

Encapsulating Entity access in EntityFramework by using the Repository pattern

EntityFramework provides a very easy way to query your entities and thus the database but it creates a very strong dependency between the calling code and the data access layer(EF in this case).

The Repository pattern allows you to encapsulate any entity access logic and also to decouple your business logic layer from your data access layer, in other words, enables separation of concerns, plus it makes unit testing a lot easier.

Consider the following entity data model:

model

And a WCF Service that exposes Orders and its aggregated OrderDetails:

public class OrderService : IOrderService
{
    private MFEntitiesContainer _context = new MFEntitiesContainer();

    public IEnumerable<Order> ListOrders()
    {
        return _context.OrderSet.Include("OrderDetails")
                                .Where(o => o.Customer.Active);
    }

    public IEnumerable<Order> ListOrdersByCustomer(int customerId)
    {
        return _context.OrderSet.Include("OrderDetails")
                                .Where(o => o.Customer.Active && o.Customer.Id == customerId);
    }
}

Lets see how we can refactor the OrderService to use the Repository pattern instead of querying the EF’s ObjectContext.

Continue reading