Do you buy the reuse story for the presentation layer in MVP and its variations? [closed]

Question

Besides the unit testing benefits, what I heard regarding MVP pattern was that the reusability of the presentation layer. So, you would design one presentation layer and use it for WinForms (rich) and Web.

I am currently working on a windows forms application in .NET with possibility of creating a web UI in the future. However, when I am designing the presentation layer and the interaction between the UI layer, I am not certain whether this notion of reusability is worth all the trouble. I sometimes feel like I am "dumbing down" my presentation for the possible web UI, when it can be so much more when designed specifically for the windows forms UI.

So, how many of you are reaping the benefits of the reusable presentation layer? Does this reusability thing pan out in the real world?

Answer 1

I'm in agreement with chills42--the goal of MVP is not to make the presenter so generic that it could be used with any UI technology. The goal is to make the models and (maybe) the controllers generic so that you can build a UI with whatever technology you want.

Again, it could be that I am misunderstanding you, but databinding isn't particularly relevant to your question (which is to say that I don't see the connection). The aim is this:

You design your application logic, also known as controllers (e.g., When Bob submits an invoice, the system does x, y, and z, and then shows Bob the list of invoices).

You design your business data, also known as models (e.g., Invoices, which have a list of line items).

Now, you're wondering, where the heck is the UI? You have something that knows how to guide your process and you have all the data you need to do it, so you just need something to show you what it all looks like. This is where the presenter comes in.

You design a .NET WinForms application that interfaces with your controllers and models. You make a beautiful form that provides your users with a way to create invoices. Then, you pass all the data to your controllers which take it, process it using the models, and then tell you what to do next. Your WinForms app happily goes on its merry (uninformed) way and does what it is told, receiving data for the next form and displaying it.

Then, your boss comes in and says, "Hey, Jiho Han, this application of yours is a total success. I need you to build me an ASP.NET application and a batch processor that'll do all this, too.

Crap. He wants you to what? Oh, no problem. You used MVP. All you need to do is build an ASP.NET UI (that follows web standards, of course) that will act as the pretty face for all your data. No problem--three days--ship it.

This is the benefit of MVP. You didn't have to rewrite all your application logic; you didn't have to write tons of queries to get your data into a different format; you didn't have to really do any work. I mean, making UIs is fun, right? Now it's up to you to determine whether you think this is worth the time, but it is expected in almost any real software that you will have some kind of separation of these components, whether it's MVP or something more enterprisey like n-tier.

Answer 2

I think that you may be misunderstanding the role or the presenter.

I would argue that the presenter should have almost nothing to do with UI, that is, the way that the information is displayed.

The presenter should take any input from the UI (whether web or winform), begin the necessary processing at the controller level, and hold the output.

The UI should have complete control over how that return is used.

Example:

Lets say you're pulling data from a database about a car.

You may pass the vehicle identification number from the UI to the presenter then ask it to return the data. When it's done processing it will hold the data returned: let's assume it has the make, model, year and last registration date.

From your UI you should be able to display this however you want, and this makes the presenter reusable. You may display all 4 items on a winform, but on a web UI for mobiles you may just display the basics (make, model, and year).

Answer 3

I think you are absolutely right with your "dumbing down" feeling.

Reusability is one of the deepest, darkest and nastiest rat holes down which a project can disappear, speaking from about 15 years of OO development experience during which reusability was trumpeted as one of the main benefits we would be getting.

Designing for reuse is like designing for performance - it should be a background guiding principle but in most cases, paying too much attention up front makes your development process bog down and causes you to over-generalise everything.

My usual recommendation is to implement the most complex, flexible GUI first and then refactor to a more reusable, generic architecture. Depending on the size of the project, do this in a prototype with some explicit goals as to what you're evaluating. You can then archive the prototype and keep it whilst taking lessons learned and some code back to the main project.

Note: the prototype if you are exploring GUI architectures needs to use the technology you're intending to use and is deep and narrow rather than the traditional GUI prototype which is done to demonstrate GUI look and feel.

Answer 4

I buy the reuse story because it worked out for me once, and because I don't expect swapping from one type of UI to a totally different type to be trivially easy.

In general, and in your case, I would expect to have to modify the Presenter quite a bit. And that's OK, that's what it's there for. It is essentially an adapter between the UI and the Domain logic. And since it helps keep Domain logic out of the UI, it's will make swapping UIs that much easier.

Oh, and BTW, web apps are starting to become very much more powerful. You may well have to smarten up your Presenter for the web!

Mike