This always drives me nuts. I'm working on a brand spankin new project that has zero code, so a co-worker and I are working on how we want to address the MVP implementation. So lately I'm reading up on new ideas that people have come with since the last time I did a ground-up implementation regarding MVP, service facades, business proxies, etc, and then most of my reading is on mocking MVP and looking at things like StructureMap and Spring.Net. My co-worker is looking at MVP stuff and Web Client Software Factory and ObjectBuilder and the like. So if anybody has any excellent resources, feel free to post them here.
Ok, so back to it, I was looking up MVP ideas and came across this page. Half way down the page it says "Controller: Code-behind .vb/.cs files" and goes on to say "ASP.NET doesnt have central controller function, instead the code-behind file can directly make request to the Model and can update the dataset. But lot of controller function can be implemented in code behind class events in .aspx or .ascx pages, like Page_Onload(), OnItem_Created() etcevents."
IMO: No, no, no.
Code-behind is View. Always. Controllers are UI agnostic and have no knowledge of System.Web at all in Asp.Net applications. Zero. Zilch. Fowler last year split the MVP into Passive View and Supervising Controller. Passive view is the more testable of the two because all behavior of the view is driven by the presenter, and is the most popular way to design MVP in Asp.Net. Presentation Model is another popular way to design MVP and is close to Passive view except it is a more view-event-driven design, which works well, but events are harder to test. Regardless of which way you go, there is a clear and obvious seperation of responsibilities, and I'm pretty sure if Fowler had written any of those to be specific to .Net, somewhere in the first or second paragraph of each one, he would say "code-behind is view code, never controller/presenter".
If you place controller responsibility into the code-behind, good luck with testing that. Your lack of cohesion goes up, your tightness of coupling goes up, extensibility drops and testability drops. Its a serious design flaw to do that, so just don't. I could send you to probably 100 different sites that talk about this if I google it, but I'll leave you to do it.
If anybody has any ideas to the contrary regarding placing controller design into code-behind, I'd love to discuss the topic. Like I said, I've refocused on MVP lately because of the new project and am loving all the new ideas I have been finding regarding designing MVP for mocking, so I'm all into talking about ideas right now.
Once we are done, I'm going to share what we came up with as an overall MVP architecture on here, but that's probably a few weeks away.