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:
- Website (MVC web application)
- 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.
- 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:
- 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
- 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?
- 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"?
- 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.