You might be interested in a Model View Presenter framework implementation for .NET – http://www.mvcsharp.org .

Regards,
–
Oleg Zhukov

Thanks for the explanations, it’s very clear and i got the whole picture of the design now. Again, thanks for the help,

Steve.

We will stick to MVC for this question because it is harder to explain for MVP. Basically, any logic that you would normally put in your code behind file would be put into a controller. Then the controller could call out to your businsses layer. This way, UI logic is on the controller and Business Logic is in your BLL.

An example of this is validation. Lets say you were doing validation on your code behind by overriding the validating methods of the code behind. In the MVC pattern that overridden validation method, in the code behind, would just be one line: Controller.Validate(). The controller will actually run that UI logic (or call out to the BLL if it is truely Business logic). Now you can also do things like implement interfaces or base classes for your controllers to force them to have methods like Validate. This way if anyone creates a new screen in your app and they use the Controller pattern, they will be forced to Validate their page. This is one small example.

Another example people can associate with is Save. Your controller has the save method and the UI just calls controller.Save(parameters) to do the actually save. Maybe your save runs some other validation at this point, in the controller, and raises an event back to the view about what to do. Or maybe your save just calls out to your BLL from the controller. The point is, everything UI related is done in the controller. And, you can inforce this with the use of interfaces and base classes.

Then, when you build testing into your application you can just instantiate controllers and call methods on the controller from your testing framework. That is the really simple answer to the question. There are lots of detailed examples on the internet (I don’t know one off the top of my head though, sorry).

Basically, I like to think of these patterns as making your Views “stupid”. You try to make the views not do that much at all. This way, the testing framework can then work with the Controller (or Presenter for the MVP pattern) to do it’s testing. I like to think of the tests in these cases as the actual View.

Now, the MVP pattern goes way more in depth than the MVC pattern, so I don’t want to try explaining it in a comment. But, the basic principal of it is that the View is even an interface and the presenter knows about the Views interface. Thus, the presenter tries to do everything for the View. This makes the View “really stupid”

I know it is a complicated subject, but after using the patterns, you will never go back. I hope I did them justice in the explanation. Just remember, Ajax or not, it really doesn’t matter. Because, it is all about how the “Server” side code interacts with the Controller or Presenter.

Greg

Thanks for the quick reply. Basically, i will be using AJAX.NET toolkit with UpdatePanel in order to update each section of the page individually. In this case, how does MVC(or MVP) fit into the presentation layer of my 3-tier web application, i.e, i have developed BLL and DAL, each of these layers will be residing in separate servers?

Thanks.