Navigation within MVP

I've been doing a lot of research into various frameworks so I can make an informed decision on my new application I'm developing. In evaluating MVP, ASP.NET MVC and the traditional three tiered approach I came across a question that I found it difficult to find informaton on. How should navigation be handled in a MVP ASP.NET application and who should handle it? Well the answer to the first question was easy, any way you like. You could use Spring.NET libraries, PageMethods, write your own, Response.Redirect, it doesn't matter and MVP doesn't prescribe any of the above. But the question that was more important is who should handle it? I found a great article on CodeProject on Model View Presenter implementation that was very useful. The article points out that a navigation raised through the presenter should be raised in the View via an event. So in a simple example if you have a login form your presenter might look like this:

public class LoginController
{
    // The view interface for manipulating the user interface.
    ILoginView view;

    public LoginController(ILoginView view)
    {
        this.view = view;
        SubscriveToEvents();
    }

    private void SubscriveToEvents()
    {
        view.OnLogin += OnLogin;
    }

    public void OnLogin(object sender, EventArgs e)
    {
        if (Login(view.userName, view.password))
        {
            view.LoginSuccessful();
        }
    }
}

And in your view you will simply implement the login successful method (don't forget to add it to the interface). This means that the business rules for navigation are actully sitting in your view layer, however if you use a navigation framework they will be well encapsulated and simple to read and understand. I have not done any investigation into which framework would be appropriate for my project, if we choose to go with MVP then this will have to be done and I'll blog that too, but in the mean time have a look at the Spring.NET libraries and PageMethods.

Application Framework Choices - ASP.NET

So I was going to blog about some of the stuff that went down at TechEd, and while that'd be fun every man and his dog who was there has something to say. For me one of the mail purposes of attending tech.ed was to get some information about emerging and existing frameworks that exist around the .NET web development sphere. For me there are a few choices that fit the requirements of our new application that we're developing here. 1. ASP.NET MVC 2. ASP.NET with the MVP pattern 3. Standard 3 Tier Architecture What am I looking for? I'm looking for a few things, with the large number of developers and the multiple team setup that we'll be using for this project there are a few things that would make life simpler to manage. In particulare the structure of the framework we choose is very important. Enforced Seperation of Concerns This is the ability for the framework we choose to force the developer to seperate the model, view and controller concerns. The benefits include more testable code, more re-usable code and more understandable code. Often the seperation of concerns is not enforced allowing the developer to code business rules into the view should they see fit, with the large team we are putting together I would consider this a disadvantage. Simplicity The chosen framework should ideally be simple. A complex framework will either add complexity to the code or add significant developer time to setup the framework for each process. Readable Too often overlooked, the application code implementing the business rules and interface should be as readable as possible. A framework that forces developers to make non-standard calls, constantly serialise or lose track of the call stack will make develop far more difficult than I would like in a large team of varying levels of expertise. Efficient Any processing overhead is a large negative. Robust A proven robust framework will ease the business' concerns when pitching the application architecture. Supported There's nothing worse than choosing a framework only to find that before the product is released it is no longer supported. Any choice made when considering the framework must consider the chance that the technology may become redundant. Productive use of Namespaces There will be an obscene amount of code requirement to complete this project. The last thing we need is to have to sift through the code to find the class we need. The framework would ideally support seperation of the code into production namespaces that will assist in identifying issues and building structure. Proven A technology that's proven in the industry will help alleviate concerns that the framework may not be able to fill all of our business needs. Fast Development Time Just like every other project, ever, our project has tight time constraints. The faster we can build code in the framework the better, but not at the risk of the attributes above. Testable We are using TDD as our testing framework for our project, whatever design framework we choose it should be as testable as possible so that we can cover as much of our code as possible. ASP.NET MVC This is a new technology currently in technical preview 5 with the beta release to come out soon. That in itself is a large risk, however a collegue of mine mentioned that the world is in perpetual beta and soon after release a technology is likely to become redundant. Scott Hanselman mentioned at his tech.ed talk that there is no such thing as a professional developer, we're all ametures. With the constant release of technology I don't believe it would be a good idea to discount a technology just because it's new. After the session on architectural considerations for the ASP.NET framework with Tatham Oddie I had some time to speak to him breifly about considering the ASP.NET MVC framework for a large production applicaiton. His response was that the project is very mature and definately worth considering as production ready. Benefits

1. Enforced seperation of concerns
2. Simplicity
3. Readable
4. Supported
5. Efficient
6. Fast Development Time
7. Testable

While the technolgy is new, it does product a very pretty code output. It is remarkably simple, but also very extendable in case it doesn't quite fill your needs. As an MS product, it is well supported and will begin to pave the way for the future of web applications under .NET. Disadvantages

1. Robust
2. Productive use of Namespaces
3. Proven

There are obvious concerns about using the ASP.NET MVC framework due to the unproven nature of the tool. Tatham Oddie did mention that Scott Hanselman has MVC in use on several projects already, and that was re-assuring, however it is a risk. The open nature of the environment helps reduce this risk, something doesn't work? Do it yourself. The biggest problem I've come across so far is the the lack of productive namespaces for controllers. You cannot create a controller with a namespace outside of the Controllers namespace, or if you do it will have no effect. I may wish to group my application into several key areas, for example /Inventory/Transactions/Edit/4 is not feasable, instead I would have to use /InventoryTransactions/Edit/4. There are ways around the URL, but the root of the problem remains the same, all of my controller names must be unique. Steve Sanderson has a good blog post (here: http://blog.codeville.net/2008/07/30/partitioning-an-aspnet-mvc-application-into-separate-areas/) on how to seperate these by extending the environment, however it is quite complex and requires overriding the default routing, also there may be gotcha's as it is untested currently. This may be a good option for us however as there is little risk in using it as we can always refactor back to the regular method without too much trouble. ASP.NET MVP Design Pattern The Model-View-Presenter framework has actually been broken up into two different types, the type I used for my prototype and testing is the Supervising Controller. They are differentiated by how much logic is placed in the view layer. MVP is not a framework in that it is something you build into your application on your own and thus a design pattern. There are many advantages of this over a framework, also many disadvantages. Firstly you get greater control over your code, you can implement as much of the pattern as you wish, circumvent the pattern where you wish and choose your own interpretation of the pattern where you see fit. This is also a major disadvantage. MVP aims to seperate concerns much the same as MVC with a 3 layer approach. Instead of a framework you plug into your application, you must develop the code to implement this stucture yourself. I did not find it very hard, and the output code was quite pretty. I made the mistake of doing a website project rather than an ASP.NET Web Project, so unit testing was quite difficult for me, however I fould the seperation of concerns to be quite simple to test and abstracting the business logic from the user interface was very easy. My biggest problem with this model is all that extra code I had to write. With MVC I implemented a form (view), a controller and a databound. With MVP I had to create the interface structure for the view layer, the ASP.NET page, bind the page to the interface, create the controller, bind the interface to the controller and verify all the events and this is without any form of data binding (which would add more difficulty to each view). Benefits

1. Seperation of Concerns (not enforced)
2. Readable
3. Efficient
4. Robust
5. Supported
6. Productive Use of Namespaces
7. Proven
8. Testable

The seperation of concerns was not enforced in MVP, the developer could easily circumvent it and the code used to do so could potentially be very hard to track down. The output code was very readable, far more than I had expected, but I would expect my developers to know the framework quite well first before they would find it easily readable. The design pattern is well used and has been around for a very long time, there is no reason for it to ben any less efficient or less robust than straight ASP.NET that I'll investigate next. I also had full control over my own namespaces, which was far more enjoyable to work with. I think my resulting code would be far more beautiful, even if it did take significantly longer to develop. Disadvantages

1. Enforced Seperation of Concerns
2. Fast Development Time
3. Simplicity

It cannot be said that MVP is simple. Compared to ASP.NET MVC is is very complicated and difficult to grasp first time around. It will take a fair chunk of time longer to develop an ASP.NET application in MVP compared to ASP.NET MVC and the seperation of concerns is not enforced. Standard 3 Tier Architecture Using code behind, a business layer and a data layer I created the same simple application using the standard 3 tier architecture. Events were tied to the code behind class and business rules were encapsulated into classes in the business layer. I used an ASP.NET Web Forms Project this time so adding in the unit testing project was a breeze, however this is where the problem with code behind comes into play. I found it very difficult to test the code behind class and there is a fair bit of code and logic required here to tie the events to the business logic. Benefits

1. Efficient
2. Simplicity
3. Supported
4. Productive Use of Namespaces
5. Proven
6. Fast Development Time

I am hesitent to put #5 into this category. My project was increadibly small and simple and the standard 3 tiered model was by far the fastest because I didn't have to learn anything and I had done similar before many times. I suspect that in a large project it would be fare more complex and the lack of seperation may become an issue. This method does allow you to setup your namespaces as you see fit, it is a supported technology just like MVP and has been proven to work many times over in other projects. Disadvantages

1. Enforced Seperation of Concerns
2. Readable
3. Robust
4. Testable

There may not be many drawbacks in this framework, however they are major. The resulting code left large chunks of very difficult to test code blocks in the view layer. This will effect the robustness of the code heavily if we are unable to adequately test as much as we would like. The resulting code is often far more difficult to maintain due to the direct tie to the view layer of the business logic. Finally the lack of seperation makes the code more difficult to read in large projects.

Results Unfortunately the results were not as conclusive as I would have hoped. Each of the three methods I investigated has their own advantages and drawbacks. I think if I can get past the fact that ASP.NET MVC has not yet been officially released and that my controller names must be unique then it would be the best framework of the lot. I think for these tools it depends a lot on the size of your project. If you have a small project then you probably cannot go past the 3 tiered approach. The time required to get the code into place will more than make up for your difficulty in unit testing the web forms over a short period. For longer projects with large a large code base I think the choice is between the other two, which you choose at this point in time will depend on your willingness to work with prototype technology. For my project, I'm going to recommend ASP.NET MVC to guage the reaction of the business in working with prototype technology verses the saved development time required to implement. I think we can get past the unique controller names without much trouble and we could implement namespace controllers as mentioned above. If they are unwilling to work with such new technology then I will happily suggest MVP (Supervisor Controller) as the alternative with the small but not insignificant extra development time it will require.