In separate data access & business logic layer, can I use Entity framework classes in business layer?
EDIT: I don't think I will need to swap out the data access layer from my business logic in the future (i.e. will be SQL Server), however I will for the UI layer. Therefore the question is more meant to be are there any major issues with using EF classes for me in the business layer? Seems like there would be less plumbing code.
Typically, the "best practice" approach would be something like this:
in your Data layer, you have EF entities that get loaded from and stored back to the database
in your Business layer, you have your own domain objects (just plain C# classes) that represent the data that your app needs to work on. Those can be more or less identical to a data layer entity, or they can contain several "atomic" entities to make up a business object, or they can be vastly different. To alleviate the need for a lot of left-hand-right-hand-assignment statements (to move property values back and forth between data layer entities and business layer objects), you should check out tools like AutoMapper that make it really easy to set up "mappings" between similar object types and allow you to easily assign those types back and forth
your UI layer(s) will then visualize and represent Business layer objects to the user for information and/or manipulation
The benefit is that your business layer domain model represents the actual business objects you're working with, and becomes more or less independent of how those are really stored in the data layer. Also, this avoids "glueing" your UI layer to a particular data access technology.
Of course - that's the recommended best practice for an enterprise-scale app, where you might need to swap out the data access layer etc. For a simpler app, you might skip those practices, knowing what you're doing, and that you're "locking" yourself into EF if you use EF entities all the way up through the business layer into the UI. If that's ok with you and your app scenario - there's no particular reason not to do it. EF entities are perfectly valid .NET object classes - they simply derive from a common base class (EntityObject instead of object) and they have a certain amount of "baggage" that comes along. But there's nothing stopping you from using those EF entities all throughout your app.
As with all questions of this nature the answer is it depends. If you want a clear seperation of your data access logic and business layer I would say no. If that is what you are aiming for I would use a repository pattern and IoC to build the data access layer then you can swap in a stub DAL for unit testing purposes and then bring in the database access when you get to the functional testing.
If you need to be able to change the way you access the database without having to rewrite to much code, you better keep EF out of the business layer. You could use the Unit of Work and repository patterns to achieve this; access all the functionality of the data tier through interfaces. If you drop EF, the interfaces stay the same, you just change the implementing classes.
However, there are arguments for not using UoW and repository, the main one being that the DbContext already provides you many of those features.
I started a project with a UoI and repository at the data layer and no EF references at the business layer. As I progressed I felt that I was just making work for myself, and dropped them. Instead I use access the context from the business tier, perform any conversion I need from DTO to business tier POCO.
In my scenario, I'm confident of sticking with EF. If you are not, consider which approach suits you.
