CODEWITHSUNDEEP
.netasp.netentity-frameworkormdata-access-layer
AJM
AJM

Reputation: 32490

ASP.NET and Entity Framework in Layered Architecture - using Entity Framework for ORM only

I have an ASP.NET application that uses a layered architecture e.g. presentation layer, business logic layer, data access layer.

I don't want to the business layer to have to know anything about how the data access layer is implemented and I'm not looking to bind the Entity's directly to a data control using the EntityDataSource or anything like that. (so a repository pattern scenario)

I'M JUST LOOKING TO USE THE ENTITY FRAMEWORK AS AN ORM TOOL TO GENERATE CLASSES. I know how to do this. What I'm not clear on is

  1. Is it advisable to propagate these classes up through the application so the business logic layer would be dealing with the partial classes created directly by the entity framework? (for instance if I have a customer table in sql, the entity fw would created a customer class which could potentially be used directly in all layers of my app)
  2. How to manage transaction support if my BLL is calling several different entity classes but wants to treat it as one transaction

Upvotes: 30

Views: 5165

Answers (6)

ckonig
ckonig

Reputation: 1234

Even if you use generated POCO classes, like the other ops are suggesting, you will still have to maintain a certain dependency to entity framework: the queries that you send to your DbContext / ObjectContext. Therefore you should consider encapsulating the queries in repositories.

Upvotes: 0

Abhay Naik
Abhay Naik

Reputation: 420

Now with the new EF4 you can also use POCO classes, thus removing the extra load of mapping the entities between layers. In our application we used EF4 and used business entities across the application other than view which required viewmodel. It gave significant performance boost.

Upvotes: 1

Ray
Ray

Reputation: 12441

Another way to do this is to use mapper classes, use what EF purely as data access and use the classes EF generated only within the DAL, then map these DAL objects to your BLL's objects through mappers. It works fine for us.

Upvotes: 2

RobD
RobD

Reputation: 1704

I suspect that this may be the answer to your problem:

http://code.msdn.microsoft.com/EFPocoAdapter/Release/ProjectReleases.aspx?ReleaseId=1580

The tool generates classes that have no entity framework dependency that you can pass across tiers.

Upvotes: 3

Binoj Antony
Binoj Antony

Reputation: 16204

Not with entity framework, but I had tried to create a sample with two insert stored procedures being executed separately in the data access layer(using data access application block 3.1), wrapped inside TransactionScope context in Service/BLL, it did not work. One insert passed, other one failed and data WAS commited.

Did you have any success doing this yourself?

Upvotes: 0

Eduardo Molteni
Eduardo Molteni

Reputation: 39453

  1. If you are practical: Yes! It will avoid you double mapping work and the potential errors generated by the double mapping. (By double mapping I mean DB -> ORM and ORM -> Business logic).
  2. Use TransactionScope. It's the best way to do transaction without worrying about nested transactions.

Upvotes: 9

Related Questions