Entity Framework in n-tier application confusion

Question

I'm building a rather large (web) application where I'm using Entity Framework to communicate with the database.

My solution is set up in layers like so:

• Client
  • Website (MVC web application)
• Server
  • BusinessLogic (contains, well, business logic. There's a lot of business rules involved in this project)
  • Repository (contains repository classes for querying the database using EF)
  • Interfaces (interfaces for defining the repository classes, i.e. IFirmRepository)
  • Model (contains my edmx file, view models, enums etc)

So, the client/UI knows about the business logic layer where the business classes needed for a given view is injected into the MVC controllers. The business logic layer knows about interfaces and model and the repository implements the interfaces.

Been developing for the last week using this approach, I have a feeling that it's not quite "correct" since:

1. The repository classes becomes bloated with a lot of methods where I need to use the Include()method to be able to work with the disconnected entities in my business logic layer
2. For every query, I'm using a new context: using(var ctx = new MyContext()) and a single business logic method might be calling more than one repository method which makes for N number of new MyContext() which isn't ideal, I guess?
3. Relating to the above: I've read about having one context per http request is the way to go when it comes to websites, which my approach seems to "violate"?
4. Out of curiousity, I tried to simply make use of the MyContextdirectly in a business logic class, making the query for the object(s) needed and then performing business logic. Doing this felt very smooth/easy and made the repository seem like a lot more work than needed and almost redundant.

So, I guess different projects needs different approaches when it comes to the architecture, but before I scratch my repository completely and making use of the entity framework context directly in my business logic classes, I'd like your opinion on this. It kinda feels wrong (in the sense that I'm violating something) to scratch the repository, but on the other hand, it's so easy to simply do the magic without first defining the method in an interface, then implementing it as a repository and then make use of it in a business logic class.

So, what is your opinion on this? :-) Am I completely off the record here, or?

Thanks in advance.

Answer 1

Go ahead and scratch the repository. If you're using Entity Framework, you don't need it. It's just a pointless layer of abstraction. I'd recommend going with a service/provider pattern. Create an interface that lays out an API that you application can utilize. The interface will be the only thing you work with directly in your web application. You'll use dependency injection to sub in a concrete implementation.

As far as that goes, you'll want to create a one or more classes that implement this interface, but only one per discrete access method, i.e. Entity Framework. You might have another if you want to work with a Web Api, for example. This implementation should be generic, but rather than having the entire class take a type parameter, instead, you'll want the individual method implementations to be generic. This allows you to instantiate one instance that can work with your entire context and any entity that it contains.

Your entities, too, should implement interfaces, so that your service implementation can reuse code. For example, instead of having GetPublishedFoos and GetPublishedBars, you can simply have GetPublished<TEntity>, where TEntity : IPublishable. If you're smart about how you set up your interfaces, your service won't need a ton of methods.

Answer 2

It sounds like you have too many repositories.

As a general rule I would try to stick to one per Database. Afterall thats your underlying repository and the Tables (objects) in it should all be related. So I can expect queries/methods lile getFirmsWithCustomer etc.

I think you are taking the correct approach in seperating EF from the business logic when you have a large application.

I would go further and say don't use EF with this pattern. EF works best for small projects where you want to skip writing the data layer. If you go the whole way with Sprocs and Repositories using SQL client will be less and easier to write code.

Answer 3

I think your question is something similar to whether to use repository pattern over Entity framework which I was also researching recently. Here is one link I found with good answers.

The Entity Framework DBContext class already implements Repository pattern. Now, if we should abstract the Entity Framework itself depends on, if this provider (EF) itself is going to change to something like web service, xml etc. In other cases better to go without custom Repository classes.

Answer 4

I would say have your service layer, use DI to get it the EF db context (you could have this context stay alive if you like). Create methods on your service layer that get and do what you need. Those methods query your data via the EF DbContext. This service layer should be used by your WebAPI and then your app calls the WebAPI. Now your back-end stuff under the service hood can be changed however you want but as long as it holds to the contract nothing else has to change downstream.

A note that you can have multiple service layers as well. Group your service layers by domain.