n-layered architecture

Tulsi · March 28th, 2012, 01:34 PM

Hello:

I am a little confused about the ASP.Net web form and the presentation layer.

The .aspx file is considered part of the presentation layer because it contains all the layout and formatting. But what about the Code Behind? This can contain business logic such as validations and other rules. What layer is the Code Behind part of?

Thank you.

Tulsi

Imar · March 28th, 2012, 02:00 PM

Hi Tulsi,

That's one of the problems with web forms and code behind. It could be anything depending on the code you write. If you use

myControl.BackgroundColor = Color.Blue;

it's the presentation layer. If you calculate a discount based on the number of items the customer has in his cart, it's business logic. If you set up a SqlConnection object and access the database, it's the data access layer.

In general, you should strive to write as little code in Code Behind and instead delegate to the appropriate layer. This way, the Code Behind becomes more of an orchestrator / controller as in MVC.

Cheers,

Imar

Tulsi · March 29th, 2012, 02:17 PM

Imar,

Thank you for the explanation.

Tulsi

Tulsi · November 6th, 2012, 03:13 PM

Imar,

I just finished reading the chapter 14 and am surprised at how powerful the ADO.Net Entity Framework is and how easy it is to create presentation pages.

I was wondering how the ADO.Net Entity Framework fits in with n-layer architecture?

Where would you put business logic specific to the photo album or picture entities. For ex, there is logic on p. 519 that creates a new file name for the uploaded picture and determines the virtual location. Would I need to create 2 separate business objects and create two classes to represent the Picture and Photo album?

Thank you.
Tulsi

Imar · November 6th, 2012, 05:33 PM

It depends on how you want to implement it. You could use the EF classes Picture and PhotoAlbum as your business entities and extend them (using partial classes) with additional functionality. However, that still ties them closely to the Entity Framework and thus to the database.

A common solution for this is to use EF Code First where you define your model classes first, and let EF handle database interaction. You then create repositories to handle stuff like getting items and updating them.

Google for EF Code First to learn a lot more.

I am working on an article series on N-Layered design using EF Code First. ETA: Unknown ;-)

Cheers,

Imar

Tulsi · December 10th, 2012, 03:50 PM

Thank you. Looking forward to the next series :)

Tulsi