Repository Pattern, POCO, and Business Entities

user_406322 0
Viewed 9471

I know there are a lot of threads here already on the repository pattern but somehow I feel my question is a little different. Maybe because yesterday was the first time I heard of the word POCO.

My question is this--usually, I have add and save methods in my business entities. Say I am writing a Q/A site, and I have the following entities: questions, answers, and comments. If I wanted to use the repository pattern, I basically need to keep only the properties in my business entities (example, Question), and move my operations to the repository class (example, QuestionRepository), right? If this is true, does POCO mean a business entity with just the properties?

I'm using Entity Framework 4.0, which created my entities in the edmx code behind. If I wanted to use the repository pattern with this, there is no need to write my own business entities (Question, Answer, etc) since they are already generated by EF, right? All I'd need is the Repository to do CRUD? And I'll be having three repositories for this example, one for each entity?

entity-framework-4 entity-framework asp.net-mvc .net c#
3 Answers

I was in a very similar place as the OP sometime ago, so I'll expand on Roberts answer with some code of how I structured my asp.net mvc app after learning about the repository pattern.

So your project is QandA

You'll have a class library project called QandA.data, here is where you will create your edmx file and all your entity framework classes. Then you have a repository for each entity like this:

public interface IRepository<T>
{
    T Save(T entity);
    void Delete(T entity);
    IQueryable<T> GetAll();
    T GetById(int id);
}

You could then have either a factory or use Dependency Injection to get the actually repositories. So:

class QuestionRepo : IRepository<Question>
{
 //call xxxEntites and get/save/delete yourentities here.
}
static class RepositoryFactory
{
 public static IRepository<Question> GetQuestionRepo()
 {
  return new QuestionRepo();
 }
}

Then down in your calling code (in your asp.net project) you have 

IRepository<Question> qRepo = RepositoryFactory.GetQuestionRepo();
Question q =  qRepo.GetById(1);

Now the advantage of doing the above is, your calling code has no idea how the entities are coming through, so you could create a mock repository to test your app out.

static class RepositoryFactory
{
 public static IRepository<Question> GetQuestionRepo()
 {
  return new FakeQuestionRepo();
  //create your own fake repo with some fixed fake data.
 }
}

Now you're calling code does not change at all if you throw it a fake or real repository.

Also, what robert talks about in his question is a ViewModel. So you would not make a strongly typed page of type Question. So you have

class QuestionForm
{
 public string Title
 public string QuestionContent
}

You're page is going to be of type QuestionForm but in your create controller, you will take the data from the question form, fill it in your Question entity and then send it off via the repository.

[HttpPost]
public ActionResult Create(QuestionForm quesfrm)
{
 IRepository<Question> qRepo = RepositoryFactory.GetQuestionRepo();
 Question ques = new Question {
 AskedDate = DateTime.Now,
 Title = quesfrm.Title,
 Content = QuestionContent
 }
  qRepo.Save(ques);
}

Robert mentions one of the reasons why you would do this, there are a few other reasons and you can read up more on view models on SO. Also check out the code for nerddinner

You may want to see these SO questions:
Should repositories implement IQueryable<T>?
Repository pattern: One repository class for each entity?

I hope it helped.

user_3680700
Related