Entities in shared layer (cross cutting concern) in a layered application?

Question

In a layered application, is it good practice to have you entities defined in a shared layer? I figure that I will be using them across all layers. Or do they belong in the business layer?

MSDN's layered application guideline puts the business entities in the business layer

The Layered Architecture Sample for .NET puts the entities in the shared layer

Can it be like this?

• Presentation
• Business
• Data
• Shared
  • Entities

Or must it be like this

• Presentation
• Business
  • Entities
• Data
• Shared

What to do and why?

Answer 1

I usually organize projects in following structure:

• Presentation (MVC application)
  • try to keep your controllers small as possible. Do not put any business logic into controllers. Relay on service interfaces instead concrete implementations. Use dependency injection.

• Business layer

  • service classes belong here and they should contain all business logic
  • i group related services into folders by feature. Each service queries the DB with entity framework and maps the results into Model (a.k.a. View Models, Presentation Objects) objects. So the service layer does not return DB entities but return POCO classes.
    • shared folder contains services which are shared across multiple services (they are more like infrastructure code but i prefer to keep them inside the business/service project)

• DAL data access layer

  • I prefer to use only entity framework without any other abstraction upon it. Some people use Repositories or implementing own unit of work pattern, but i do not recommend to do this. Entity framework is already implementing unit of work and encapsulating database selects with linq so there is no need for more abstraction.
  • this layer contains only Code First classes (entity framework entities)

Answer 2

I would say it depends if these entities contain business logic or not.

From the Layered Application Guidelines :

Business entities also validate the data contained within the entity and encapsulate business logic to ensure consistency and to implement business rules and behavior.

In contrast, the Layered Architecture Solution Guidance seems to rely on code generation to create Entities, they are mere data containers with little to no logic in them.

Rich domain entities tend to not be in a Shared module, since it would mean carrying around a ton of behavior that you don't want everyone to have (imagine being able to manipulate business logic directly on the client side...) Anemic ones on the contrary are lightweight and may be happily and conveniently distributed everywhere.

Answer 3

My approach is a little bit different. In data layer I store all my entities and in shared layer I have DTO object (Domain Transfer Objects) which are exact copy of entities but without Entity Framework control. To map each other, I'm using mapper (AutoMapper) which is fluent and easy to use.

I can't understand why Entity Framework doesn't support interfaces, using only instances.