Building a Decoupled N-Tier App With Entity Framework and VB.NET

Question

So we are building an application with a

• UI Layer (web, mobile, Ajax client, etc)
• Service/API Layer
• Business Logic Layer
• Data Access Layer

Our goal is to have an Entity Framework dependency from the Service Layer on down to the DAL. That means the Sevice layer will only accept and return POCOs (plain old CLR objects).

What we're currently doing is manually coding a mapping layer between the service layer and business logic layer that will convert POCOs to EF Entities and vice versa.

So in short, page has form, form has codebehind that takes form contents, stuffs them into a POCO, sends it to service layer. Service layer converts to EF Entity, sends it to Business Logic Layer which performs certain transformations to the entity, and then interacts with the DAL to get it persisted.

Yes, its a bit tedious, but we were wondering if theres a better way?

Yes, I know someone published an EF Poco Adapter but it's all in C# and we would prefer a VB.NET solution.

Yes, Switching to NHibernate is an option of last resort, as we are already deep into our development cycle.

Answer 1

You should be performing business logic on POCOs. The entire purpose of ORM is that it is an implementation detail. The business logic should be implemented in the domain model and in the domain services - in a business application, "domain" means "business". The DAL should be there to take a POCO and persist it - in your case, that means mapping it to and persisting an EF entity.

That's the theoretical / NHibernate model, at any rate.

Answer 2

Can you stand having a dependency in the service layer on the EF interfaces? You could implement IPOCO.

There's even a way to do it automatically.