Repository and Interface Re-use between Databases

16. August 2010

When using Entity Framework you run into the problem of having either one repository object for each database or having to not use an Inversion of Control due to having to new the Entities Context each time. I have found that this hit on the architecture side is not required.

This is a follow up to the POCO and Context separation post here. It uses that separation to avoid circular references.

Lets start with our Generic Repository and Interface.

public class EntityFrameworkRepository : IRepository
    {
        private ObjectContext _entities;

        public EntityFrameworkRepository(ObjectContext context)
        {
            _entities = context;
        }

        public IQueryable<T> FindAll<T>() where T : class
        {
            return _entities.CreateObjectSet<T>();
        }

        public IQueryable<T> Find<T>(Expression<Func<T, bool>> where) where T : class
        {
            return _entities.CreateObjectSet<T>().Where(where);
        }

        public T Single<T>(Expression<Func<T, bool>> where) where T : class
        {
            return _entities.CreateObjectSet<T>().Where(where).Single();
        }

        public T SingleOrDefault<T>(Expression<Func<T, bool>> where) where T : class
        {
            return _entities.CreateObjectSet<T>().Where(where).SingleOrDefault();
        }

        public T First<T>(Expression<Func<T, bool>> where) where T : class
        {
            return _entities.CreateObjectSet<T>().Where(where).First();
        }

        public T FirstOrDefault<T>(Expression<Func<T, bool>> where) where T : class
        {
            return _entities.CreateObjectSet<T>().Where(where).FirstOrDefault();
        }

        public T Add<T>(T entity) where T : class
        {
            _entities.CreateObjectSet<T>().AddObject(entity);
            _entities.SaveChanges();
            return entity;
        }

        public void Delete<T>(T entity) where T : class
        {
            _entities.DeleteObject(entity);
            _entities.SaveChanges();
        }

        public T Attach<T>(T entity) where T : class
        {
            _entities.AttachTo(entity.GetType().ToString(),entity);
            _entities.SaveChanges();
            return entity;
        }

        public int SaveChanges()
        {
            return _entities.SaveChanges();
        }
    }
public interface IRepository
    {
        IQueryable<T> FindAll<T>() where T : class;
        IQueryable<T> Find<T>(Expression<Func<T,bool>> where) where T : class;
        T Single<T>(Expression<Func<T, bool>> where) where T : class;
        T SingleOrDefault<T>(Expression<Func<T, bool>> where) where T : class;
        T First<T>(Expression<Func<T, bool>> where) where T : class;
        T FirstOrDefault<T>(Expression<Func<T, bool>> where) where T : class;
        T Add<T>(T entity) where T : class;
        void Delete<T>(T entity) where T : class;
        T Attach<T>(T entity) where T : class;
        int SaveChanges();
    }

Notice that we pass in the Object Context. This is what enables us to separate the usage from the declaration. I am going to use Structure Map as it is my preferred IoC but most IoCs implement this functionality.

image

This is in the configuration code block for Structure Map. Notice that the ObjectContext is created to a named instance of the IRepository. The application services are created with the database that they hit. This allows you two things.

1. Re-use of the interfaces and repository objects between databases.

2. Changing the database for a service is now just an IoC Configuration Change.

 

Enjoy.

Design Patterns, Entity Framework

Separating POCO and Context in EF 4.0

16. August 2010

I found that I like the streamlined process of working with Entity Framework. The auto generation of domain class is nice when dealing with Existing databases. I dislike having to put domain classes in Infrastructure or putting data base context in Core.

Using the POCO Entities T4 templates you can separate these.

Download here

Add a new Entity Data Model and Generate from the data base.

image

Then right click the background of the model and add a generated code item.

image

Select the POCO Objects

image 

This will create Two .tt files. One is the POCO Classes and one is the Context. We are going to use the onion architecture for this example. We want to move the context to infrastructure so that our model and POCO classes and model are in core.

image

and

image

To separate the context from the Domain we will need to edit the context template. You do not want to edit the classes generated because this will just get wiped out.

image

image

The edit we have to make is to simply add the namespace of the Domain objects to the using statements, and the path of the EDMX file to the input. I am still hunting a way to keep from hard coding a absolute path to the EDMX but until then this will have to work.

 

Enjoy.

C#, Data Access, Design Patterns, Entity Framework

Geek Handbook

11. August 2010

I just got done reading “Being Geek”. It is awesome. I would recommend it to any geek that it is the business of IT.

Product: Being Geek by O'Reilly Media

Awesome Handbook

Pros:

Easy to understand, Accurate, Enjoyable, Concise, Well-written

Best Uses:

Novice, Expert, Student, Intermediate

Describe Yourself:

Designer, Educator, Developer, Maker, Sys Admin

This is going to be a book that I have dog-eared, worn-covered, and close at hand. The interview personality section and the offer negotiation sections were incredibly helpful. The conversational style of the writing makes it a very easy read. I found that I was enjoying reading it and laughing and things like the bridge game. I got this book for writing another review and I have to say that it is an awesome find.

Book review

jQuery Cookbook

3. August 2010

jQuery Cookbook by O'Reilly Media

Pro. Dev take on the book

by Devlin Liles from Springdale, AR on 8/3/2010

Pros:

Well Organized, Well-written, Concise, Accurate, Helpful examples, Easy to understand

Best Uses:

Expert, Intermediate

Describe Yourself:

Developer

I have been a professional developer for 4 years now mainly focused in the windows services and back ground communication pipelines. I was asked to pick up support for an app written with a lot of jQuery. I was given "jQuery Cookbook" by a friend and I fell in love. It is straight into the meat. Normally I have to wait 2-4 chapters before the useful stuff gets going and with the cookbook I was diving in right away. I haven't written any jQuery before reading the book but I did understand javascript and the DOM. With that foreknowledge the book made jQuery so amazingly easy. I could not have picked up jQuery in 2 short weeks without this book. I recommend this book to any professional developer that is looking to add jQuery to their skill set.

Book review