Setting up an EF application's structure

Question

I'm working on a prototype EF application, using POCOs. Mainly as an introduction to the framework I'm wondering about a good way to set up the application in a nice structure. Later on I'm planning to incorporate WCF into it.

What I've done is the following:

1) I created an edmx file, but with the Code Generation Property set to None and generated my database schema,

2) I created the POCOs which all look like:

public class Person
{
    public Person()
    { 
    }

    public Person(string firstName, string lastName)
    {        

        FirstName = firstName;
        LastName = lastName;
    }

    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

3) I created a Context

public class PocoContext : ObjectContext, IPocoContext
{
    private IObjectSet<Person> persons;

    public PocoContext() : base("name=PocoContainer", "PocoContainer")
    {
        ContextOptions.LazyLoadingEnabled = true;
        persons= CreateObjectSet<Person>();
    }

    public IObjectSet<Person> Persons
    {
        get
        {
            return persons;
        }
    }

    public int Save()
    {
        return base.SaveChanges();
    }
}

The interface looks like this:

public interface IPocoContext
{
    IObjectSet<Person> Persons { get; }

    int Save();
}

4) Lastly I created a repository, implementing an interface:

public class PersonRepository : IEntityRepository<Person>
{
    private IPocoContext context;

    public PersonRepository()
    {
        context = new PocoContext();
    }

    public PersonRepository(IPocoContext context)
    {
        this.context = context;
    }

    // other methods from IEntityRepository<T>
}

public interface IEntityRepository<T>
{   
    void Add(T entity);
    List<T> GetAll();
    T GetById(int id);
    void Delete(T entity);

}

Now, when I get on playing around with this, this design dictates me to instantiate a repository every time I want to fetch or mutate some data, like this:

using (var context = new PocoContext())
{   
    PersonRepository prep = new PersonRepository();

    List<Person> pers = prep.GetAll();
}

Somehow this just feels wrong and flawed, on the other hand, just instantiating every repository in the derived context doesn't feel too good either, because of potentially instantiating objects I might not need at all.

Any tips on how to make this design sound? Should I leave it this way? Any things I should add or avoid in general when doing this?

Answer 1

I don't understand this part:

using (var context = new PocoContext())
{   
    PersonRepository prep = new PersonRepository();

    List<Person> pers = prep.GetAll();
}

Why are you creating the context in outer scope if you call repository constructor without passing the context as parameter? Using multiple contexts will make things only much harder. Also what is the point of making the interface for repository and trying to hide it if your outer block will just create instance of the class?

Is your approach correct? Generally yes. You should use single context for logical operation (unit of work) and if your repository gets context through constructor you need to create a new set of repositories for each context. This is usually achieved through dependency injection.

just instantiating every repository in the derived context doesn't feel too good either, because of potentially instantiating objects I might not need at all.

Well this can be solved pretty easily by lazy initialization:

private SomeRepositoryType _someRepository
public SomeRepositoryType SomeRepository
{
    get { _someRepository ?? (_someRepository = new SomeRepositoryType(context)) }
}

But I would not put this into context itself. I would probably use this in some data access factory because it should be outside of the context and passing single factory as injection to classes / methods using multiple repositories is simpler.

Btw. what value will you get from using repository?

Answer 2

If you use POCO to create model of your database, maeby try EF Code First? IMHO using Code First is more clearly than creating EDMX model in designer.