Entity Framework DAL, BLL with Repository Pattern - asp.net

Question

I am trying to build a three tier architecture with UI, BLL, and DAL. I am using the Entity Framework with the repository pattern.
My question is: Are the Entities generated by the Entity Framework supposed to act as a part of my BLL or are these just DAL objects?
Reason for asking is because It feels like I am duplicating code. For example: I have a DAL.CatEntity which is generated by the Entity Framework directly from my database. This all fine and dandy. I then use my repository (which is part of my DAL) to pull data into a DAL.CatEntity. I then use this DAL.CatEntity in my BLL, pull out all of it's data, and transform it into a BLL.Cat. I then use this BLL.Cat in my UI layer.
Below is some super simplified code.
BLL
public Cat GetCat(string catName){
CatEntityRepository _repository = new CatEntityRepository;
Cat cat = null;
CatEntity catEntity = _repository.GetSingleCat();
cat = ConvertToCat(catEntity);
return cat;
}
private Cat ConvertToCat(CatEntity entity){
return new Cat(){
Name = entity.Name,
Color = entity.Color,
//....
}
}
UI:
public ActionResult method(){
Cat cat = BLL.GetCat();
//......
}
It seems unnecessary to have BOTH Cat and CatEntity. Can I just use my EntityFramework Entities as part of my BLL while using the Repository as my DLL?
Thanks.

Answer 1

Ultimately, whatever you do is up to you. Most apps are somewhere between ideal and horrible, in the land of pragmatic and practical.
What you need to do is look at the complexity of your app. The more complex it is, the more it will benefit from high degrees of separation. Often times the simplicity of the app just doesn't justify the large amount of work needed to create clear layers.
Having said that, in my opinion, in a large number of small to medium complexity apps, you can effectively treat your entities as business objects. In particular, if you make the entities POCO's and part of your business layer, then use those entities in your EF DAL, it can be quite efficient.
I would always caution, however, sending business or data objects directly to the UI. You should have dedicated UI objects that are translated between business and UI.
I think it makes the most sense to keep a strong separation between business and data when you might change your data access methods. For instance, if you think you may change to a web service to get your data rather than using EF directly. Also, strong separation of concerns helps a great deal with unit testing.

Answer 2

If you feel that you are duplicating code then you probably don't need a service layer and your EF entities could act as business models. This is often the case with simple CRUD applications in which you don't need a business layer.

Answer 3

An alternative approach is not to CONVERT between tewo types of objects but rather, create interfaces out of your domain entities and code your repositories against interfaces.
This way you bake two cakes in the same time. You don't convert your data layer entities to bll entities snd still you are not messing layers (in a sense that your repositories don't work on concrete data layer types).
This approach is suprisingly useful and yet rarely described.