Use of context and repository in EF WCF services

Question

I am using Entity Framework code first in my data layer using the repository pattern. I'm currently designing my WCF web services to connect to the data layer and I'm just a little confused about how to link up with the data layer.

In my test project for the data layer I create a new DbContext class for each test, wrap that in a using block, within that I create the repository class, passing in the context as the constructor parameter. I can then call my methods on the repository to get the data back.

Is this correct for a start and then do I do the same in the WCF service methods?

Eg would I have

 public class UserService : IUserService
    {
        public bool CheckEmailAvailability(string email)
        {
            try
            {
                using (var context = new MyDbContext())
                {
                    var repository = new UserDataRepository(context);
                    var emailAvailable =
                        repository.GetItems().Count(
                            u => u.EmailAddress.Equals(email, StringComparison.InvariantCultureIgnoreCase)) == 0;

                    return emailAvailable;
                }
            }
        }
    }

Or am I using the context/repository concept wrong?

It also strikes me that it would be handy to use DI here so I could mock the data context/repository objects in a WCF service test project. Is this something usually done and if so, does anyone have any links to an example or tutorial on this?

score 1 · Answer 1 · edited May 23 '17 at 11:59

First of all, yes it would be better to inject the repository, or (if your chosen DI framework is unable to resolve them) a factory for the repository.

Additionally it might be a good idea to remove the idea of the context from your service. To my mind the repository and it's helpers should deal with the context, and if necessary with sharing the context between various DB calls required to assemble your entities. Then the services can request entities from the repositories without worrying about whether they're being source from a DB or some other data-store.

public class UserService: IUserService
{
    IUserRepository userRepository;

    ... // ctor to inject repository

    public bool CheckEmailAvailability(string email)
    {
        var emailAvailable = !userRepository.GetUserEmails().Any(u => u.EmailAddress.Equals(email, StringComparison.InvariantCultureIgnoreCase));

        return emailAvailable;                            
    }
}

public class UserRepository: IUserRepository
{
    ...

    public IEnumerable GetUserEmails()
    {
        // actually this context should be handled more centrally, included here for sake of illustration
        using (var context = new MyDbContext()) 
        {
            return repository.GetItems();
        }
    }
}

Finally, with regard to WCF services, I'm not certain what the best advice is. I've seen code where WCF services were created in the middle of business logic, which was awful, but a limitation of the oldish WPF code-base and limited DI. The better situations are where a ChannelFactory or service factory can be injected into your service layer. You may find this answer on Dependency Injection wcf helpful.

And as always, if you're planning to TDD your code, I'd definitely recommend wrapping the intersection points between layers of your application in interfaces so that they're easier to mock out. It sounds like you've got the right idea there.

I have been debating about which way around to have the context and repository and agree it seems to make more sense to just have code deal with repositories. The problem is if you have to then do a query on the results, eg you have a method called GetItems() on the repository. Within this, you create a context in a using block, select from EF and return the results as a Queryable(). You can then not query the items in your calling method as the context has been disposed — NZJames, Jan 21 '14 at 12:19
Ah, I see. I must confess that I'd forgotten that particular wrinkle with EF. In my last project that used EF for more than a DB definition, the initial select would be made from EF in the repository (eg. select by emailaddress or select all) and resolved as a collection, then the business logic would use linq to do what-ever else it wanted with the returned collection. In my experience a lot of the time EF is more trouble than it's worth, and alternatives like SimpleData are easier to work with. I hope this helps. — Stark, Jan 21 '14 at 12:55

Use of context and repository in EF WCF services

1 Answers1