N-Tier Development with Model-View-Presenter and Testability (Part 3)
N-Tier Development with Model-View-Presenter and Testability Series
Part 1 - Intro
Part 2 - Tiers Overview and Business Tiers
Part 3 - User Interface Tiers
In this third part of the series we´ll be seeing how to implement the UI tiers with reduced coupling, maximum reuse and cohesion of our code.
First let´s get back to the picture from last part.
In the last part of the article we checked out the Data Store Tier, the Persistence Tier, the Business Objects Tier and the Business Rules Tier. These four tiers are the core of our application. They store, process and serve the data for our users to manipulate. They make sure that the users data are stored in a valid, safe and performatic way. These tiers are the Business Tiers.
Now we´ll see how to give access to all this things to our users: the User Interface Tiers, the UI. We´ll learn more about the Interface Rules Tier, the MVP Tier and the Presentation Tier now. These tiers represent our UI Tiers.
Interface Rules Tier
The Interface rules tier is a complement of the Business Rules tier. The Business Rules tier´s focus is to work with domain objects. In the UI we´ll hardly work with domain objects, which will only happen in databound controls. This is because of the easiness of setting properties that we have with the Model-View-Presenter Pattern*. Since the Presentation tier (and MVP Tier by extension) will work primarily with primary types, and the business tiers work with business objects, we must have some tier that makes the translation for them. Let´s check an example.
You remember our SaveNewOrder(Business.Objects.Order order, bool verifyInventoryLevels) method from the OrderManager in the last part right? Well you can see right away what this method does. It saves a new order based on the data from the order parameter. But our UI has all these text boxes and dropdown lists that translate to primary types in the MVP Contracts. This is where our OrderManager from the Interface Rules Tier comes into play.
The OrderManager from the Interface Rules Tier (I know it has the same name from the Business Rules one, but since they are in different namespaces no harm done) is the one that maps data from the UI model to the business model. So the SaveNewOrder method becomes:
SaveNewOrder(int customerId, DateTime deliveryDate, double totalPrice,
int deliveryAddressId, int billingAddressId, bool verifyInventoryLevels)
You can see right away that this version of the SaveNewOrder method does get a lot more parameters. That´s ok, since the contract for the New Order UI will probably have all these properties.
You´ll ask why is this any good? Why don´t use Domain Objects at the UI level? The method could be easily rewritten like this:
SaveNewOrder(Customer customer, DateTime deliveryDate, double totalPrice,
Address deliveryAddress, Address billingAddress, bool verifyInventoryLevels)
The rationale behind this decision is performance. If you keep using domain objects in the UI there´s a very good chance that in every single call to a property or a method people will just make a new Customer(customerId) (or a factory method, depending on the case). The reason that this isn´t good is that each call would incur in a trip to the data store, which as we all know is a very expensive operation. Using domain objects in the UI without care can easily escalate into a very low-performatic application. That´s why we only use them in the UI when it´s for databinding, since we make one call, get a collection and databind it.
This is the only tier that I´d say would be optional, since you could pass objects around in the UI tiers. If you go down this road, and decide to make the properties in your MVP contracts being Business Objects, please take extra caution with roundtrips to the data store. You´ll see that the users of your application will thank you.
*If you´d like to learn more about the MVP Pattern, the first three chapters of my book on the NMVP Framework are available as a PDF here in my blog. The book is yet to be completed though. It´s always a good idea to check http://www.martinfowler.com. His website is filled with enterprise patterns.
Model-View-Presenter Tier
This is the tier that I´ve started using just a few months ago. It´s a very exciting concept since it allows almost zero-coupling between the Presentation Tier and the Interface Rules Tier. What I mean is that we can build the whole UI logic without coupling it to the Presentation. So you could have the same code to govern a Create Order UI being used in ASP.Net, Windows Forms or Windows Presentation Foundation, for example. Another great advantage is that this is the tier that enables you to effectively unit test your UI. Unit testing ASP.Net or Windows Forms can be quite time-consuming, but unit testing MVP structures is rather easy (I feel like those TV guys selling George Foreman Grills).
In this tier we´ll define our Contracts and our Presenters, with good samples being INewOrder and NewOrderPresenter<INewOrder>, respectively.
This tier governs the interaction between the user gestures (handed over by the presentation tier to this tier) and the Business Logic (represented by the Interface Rules Tier and all the Business Tiers).
This is the last layer that is reusable in a sense that it can be reused if you have many different presentation types (Windows, Web, Mobile, etc) and for unit testing without any modification.
Presentation Tier
The Presentation Tier is sometimes referred as the "views tier". That is because in the Presentation tier is where our views lie. By views you can understand any web form, windows form, user controls or anything else that implement an MVP contract in a graphical way (thus handling user gestures).
This tier is the one with lesser abstraction, since it´s only purpose is the one that it was built for: displaying data and enabling data processing. This is acceptable though, since this is the concrete implementation of your application. So it makes sense that it´s not very abstract.
This tier can be implemented in many ways: ASP.Net, Windows Forms, .Net Mobile Framework, Windows Presentation Foundation or anything you can think of and can implement the MVP contracts.
This is a rather difficult tier to unit test and thus I´d leave this one out of the Code Coverage policy. If you can unit test your MVP tier properly you´d hardly have any issues in this tier.
Conclusion
Again not the end of our series. We haven´t even discussed the organization of our solution and how to enable testability! There´s a lot more coming in the next days.
Today we learned about the User Interface Tiers. These tiers are the interactive part of your application. They model how the user experience should be when using your application. I´d enforce the use of graphical patterns here, like CSS (if you are in a web site) . Make sure you follow a logical set of rules so your interface is consistent.
Post Number 100!
Yes today I achieved my 100th post! I´d like to thank a lot to you readers of my blog (yes you three! kidding hehehehe) and to my good friends who keep me going and say very nice (and undeserved!) things about me. Thanks for being so kind! I hope I can make to post #1000! See you in a few posts...
#100