MVC .NET codebehind a controller?

[cappmgr]

I was a talking to a co worker about the MVC pattern and I stated we should we should not have BL in the vew I include the codebehind as being part of the view.
He disagreed. Here is the email and response that took place the next day.

From Patterns of Enterprise Application Architecutre by Martin Fowler
page 330 Model View Controller

"The view is only about the display of information; any changes to the information are handled by the third member of the MVC trinity: the controller. The controller takes the user input, manipulates the model, and causes the view to update appropriately."
There is much more in the chapter stating why there should be no BL in the view.

You are supporting MY view (no pun intended, OK maybe just a little). MVC is a PRESENTATION pattern. In ASP.NET the ASPX file is essentially the view. The code-behind is essentially a controller. In our application the controller classes (misnamed unfortunately, I blame the User Interface Process Application Block for that) essentially represent the model.

You are misinterpreting the View to be THE whole presentation layer (A Presentation layer as expected in a 3-layer architecture). That is just plain wrong. The presentation layer needs all three parts of the MVC pattern and more.

In a 3-layer application the presentation layer should be replaceable. This is even more true in applications that are supposed to be service-oriented. What business does the business-layer have decoding and interpreting the data the presentation layer is supposed to present. Particularly in a service-oriented application the business layer has no responsibility to message the data so it is in a nice tight format for the Presentation-layer. The BL should feed, via a web service, the data requested by the PL. It is the responsibility of the PL to present the data.
Plain and simple. As applications become more and more interconnected via web services and the like, it just makes no sense for the PL to expect the BL and DL to do all the work - the BL and DL very well may be parts of completely separate applications which certainly have no responsibility for knowing or caring in what format the PL would like the data. The PL gets the data it is served. It DOES make sense that the PL has to be smart enough to be able to interpret and digest the data it receives so it can effectively present the data.

And I am not contradicting Fowler, Fowler and I share the same view (haha, did it again). But I don't think Fowler describes any architectural patterns similar to the 'Three-Layer Services Application' as described in Microsoft's Enterprise Solution Patterns Using Microsoft .NET. In other words, I don't know of any patterns in PoEAA that discuss the responsibilities of Presentation, Business, and Data layers, so I am not really sure this discussion can be resolved by anything in PoEAA.

Just looking for opinions.
Thank you,
Marty

 

[BobRodes]

Some of the terms are ambiguous. "Interpret and digest" can mean a great deal of things, some of which I would not assign to the PL. The PL should not expect the BL and the DL to do all the work, of course--work which is appropriate to the PL (e. g. showing negative numbers in red) should be done by the PL. Other work shouldn't.

"Decoding and interpreting" data can mean a lot of things. For example, I would call "applying business rules" to data "interpreting" data, and would therefore feel that that's the bailiwick of the BL.

So, in my opinion, your semantics aren't clear enough to express my opinions with any degree of accuracy.

Bob