Entity Framework in n-tier application confusion

asp.net-mvcentity-frameworkn-tiernet

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.

Best Answer

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.

Related Topic