5

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?

duress
  • 77
  • 7
  • What kind of application is it. Webservice, WPF-app, something else? – alun Aug 05 '11 at 06:51
  • In this state it's just a console application, since it's just a bare-minimum prototype. – duress Aug 05 '11 at 06:54
  • 1
    The reason I ask is that how you handle your context is heavily influenced by the type of application. It's common for instance to have one context per form in a wpf app and one context per http-request in a web app and one context per method call in a webservice. – alun Aug 05 '11 at 07:06
  • Eventually the goal of this exercise is to get to know both EF and WCF, so after I get my setup right, I will refactor this into a WCF centered application. – duress Aug 05 '11 at 07:13

3 Answers3

2

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?

Community
  • 1
  • 1
Ladislav Mrnka
  • 349,807
  • 56
  • 643
  • 654
  • I thought about that after reading your post and hope you can comment on what I'm going to say. First of all, this project is mainly inspired by a tutorial and during lunch this afternoon I was asking myself the same exact question the starter of this topic did. The repositories just add an extra layer I call AddObject (or whatever) in. That said, come to think of it I actually think I don;t benefit from this at the moment... – duress Aug 05 '11 at 14:37
1

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.

Piotr Styczyński
  • 482
  • 4
  • 10
  • Yeah it is, but in this case I can pick some stuff about how the edmx is set up as well. – duress Aug 05 '11 at 07:47
  • Really, follow this advice and use Code First. You have no reason to mess with EDMX in the first place. And if you really want to see what the edmx would look like, there's an option to generate it from code first classes. – Matteo Mosca Aug 05 '11 at 08:48
0

Use Dependency Injection using any container like Castle Windsor, AutoFac , etc by providing per request Object Context.

marvelTracker
  • 3,459
  • 1
  • 32
  • 48