I am working on my first public-facing web application and I’m using MVC 4 for the presentation layer and EF 5 for the DAL. The database structure is locked, and there are moderate differences between how the user inputs data and how the database itself gets populated. I have done a ton of reading on the repository pattern (which I have never used) but most of my research is pushing me away from using it since it supposedly creates an unnecessary level of abstraction for the latest versions of EF since repositories and unit-of-work are already built-in.

My initial approach is to simply create a separate set of classes for my business objects in the BLL that can act as an intermediary between my Controllers and the DAL. Here’s an example class:

My primary concern: Is the way I am instantiating my DbContext as a private property thread-safe, and is it safe to have a static method that instantiates a separate DbContext? Or am I approaching this all wrong? I am not opposed to learning up on the repository pattern if I am taking the total wrong approach here.

In my experience, you can new up a DBContext on each repository call without too much penalty, and you won't have to think about thread safety at all if you do. The DBContext object is meant to be relatively lightweight.
–
Robert HarveyOct 27 '13 at 1:50

Thanks Robert. So what would be the difference if I called a new DbContext from a Repository vs. calling it straight from my business object class as I have now in my code?
–
bnice7Oct 27 '13 at 2:03

Maybe you could rethink using EF and use something more lightweight like Dapper? ( code.google.com/p/dapper-dot-net ) The argument is, that EF (and ORM in general) adds tons of complexity. And if you can't map it nicely to DB, then it will be real pain in the ass later.
–
EuphoricOct 27 '13 at 8:59

The reason I chose EF in the first place is primarily because the database structure is out of my control, having been developed by a separate group. They can manipulate it, but I can't. The idea of them making schema modifications and me having to re-write a bunch of SQL to accommodate changes is exactly what pushed me to use an ORM. Instead, I can regenerate POCOs and adjust my domain classes as necessary (still a pain in the ass, though). Dapper is enticing for performance and I realize there are other ORMs out there but we are not looking at a very large user base.
–
bnice7Oct 27 '13 at 15:21

1 Answer
1

Because the database schema is both out of your scope and liable to change, it is extra important that you isolate it from your main code base. The mapping and table manipulation operations you are calling from your Create and GetList functions and should ideally live in your DAL. That way, your entities and business logic classes will be unaffected by unexpected changes to EF generated code. Even major changes to the database schema then become merely a matter of changing the mapping functions.

Other that that, I would avoid having business entity instances that have calls to load other instances of their own type - it smells of single responsibility principle violation, as your MyBuikding instances are both data finder objects and data entities. You could get your entities directly from calls to your DAL repositories, or via some intermediate service layer calls if you will require business logic.