Three tier architecture question

Question

Hello!

I have an ASP.NET app with a three layer architecture:

• Presentation layer: ASP.NET

• Bussiness Layer: C# library.

• Data Access Layer: C# library with
  ADO.Net Entity Framework objects.

Some methods on Bussiness layer would return ADO.NET entity objects but, data access layer is not visible at Presentation layer I can't do that.

My question is: On a design view, Is it correct to expose Entity Objects in the Presentation Layer? I think I only have to link Data Layer library with ASP.NET app.

Thank you!

Answer 1

It's absolutely desirable to have your entity objects available for use and consumption in your presentation tier. That's what all the work is for.

• Binding collection of objects to a grid/listview/dropdown
• Splashing a single object (i.e. customer) onto a form for read/update/delete

This makes your life easier by far. Otherwise you'd have to pass string after int after double after string between your presentation and business layers.

These may be Entity objects or even your own POCO objects that were hydrated from the Entity objects.

I would even go so far as to say that your Entites should be in their own assembly separate from the DAL.

Answer 2

I think no, it is not, the best way to do that is to separate data classes from behavior, and reference only data classes in presentation level.The good approach I think to use WCF see this link

Answer 3

See Supervising Controller and Passive View

If you pass the Entity, you are essentially Supervising controller. Otherwise you are Passive View.

Supervising controller is less work, but less testable. Supervising Controller also says databinding is OK. Passive view is testable but a LOT more work. No databinding. Lots of properties.

Typically I stick with Supervising Controller. You typically don't need that level of testability and it isn't worth the extra trouble.

Answer 4

I suggest that you look into the concepts of View objects...or Data Transfer Objects (DTO). You might consider using a tool like AutoMapper or similar which will create a view specific domain object out of your entities. In general you may have screens that need an entity present to perform its work. But more often than not you will need to pass several different entities. In this case you are better off creating one DTO that contains all of these entities. By doing this you are adding a layer of separation between your presentation layer and your business layer. Often times your entities have more power than you might want to expose to your presentation layer. And...vice versa. Frequently you may need to get some UI messages out to the presentation layer based on some validation flagged in your business layer. Rather than make your ui more complex than it needs to be (by passing in your full entities) you can only pass in what the UI needs in the form of the DTO. Also, there is never a need for your business objects to care about anything specific to the presentation layer. I suggest that you not databind directly to anything as far back as the data access layer. Technically your presentation layer should know as little as possible about your business layer. In the case of MVP or MVC this is very easy to achieve by disconnecting the front end and the back end by way of this additional separation!