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?

Gnarly

Answer 1

The value of MVC/MVP really lies in two different separations.

Separation between your presentation layer and your models (however you decide to implement them) is one of the more important principals software design for anything but simple systems. If you have any business logic or nonvisual logic in your application, you will definitely see the benefits of that separation.

The separation between presentation layer and controller seems a little less important to me. In rich client applications, you'll rarely see benefit from this separation; in web front ends, it's a lot more common (e.g., ASP.NET aspx and code-behind or J2EE jspx and servlet).

Maybe I don't completely grasp the way you've explained MVP, but I wouldn't say that one of the benefits is the reusability of the presentation layer--rather, I would say that the primary benefit is the reusability of the models. This is also one of the primary benefits of using any n-tier system. If you want to expand and build a new type of front-end (e.g., WinForms, WPF, etc.), you can do so without trying to separate all your logic out of the web application you just built.

Autochthonous

I agree with you about the Model layer. However, is the separate Presentation layer's only benefit, the testability (besides nice/clean code)? Think of the MVP vs. traditional ASP.NET WebForm. After you've separated out the P, could you use the P for WinForms? Would that be worth it? – Gnarly

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).

Joleenjolene

Answer 3

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.

Autochthonous

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

Joo

Answer 5

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.

Multure

Answer 6

MVC is good pattern to use even if you will end up using it just for one frontend. It helps you design application with cleany seperated parts. This brings several benefits.

It eases up the automated testing of parts, for instance you can call your models directly, without the need of gui.

Since there is clean line of separation its easier to redesign parts of application, without breaking other code (for instance redesigning GUI).

Having several smaller (and independent as possible ) parts, rather than one big jumble of things makes it easier to debug.

Introducing new programmers to the code will be easier since they can explore one logic part at a time.

Generally speaking MVC is nice OO way to design applications since it provides you with natural way to encapsulate your app at high level.

Laoag

I'm not arguing against the separation of concerns. I completely buy the M-V-P(C). What I am asking is whether the effort to make the P commonly usable from multiple UIs is worth it or even practical. – Gnarly

Answer 7

chills42,

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

I believe I understand the role of the presenter just fine.

I don't doubt that you CAN make the presenter generic so that it works for any UI. My question is whether that is worth the effort while losing the opportunity to take advantage of the advantages a certain UI platform can provide.

Think databinding on the WinForms. By implementing certain interfaces (IDataErrorInfo, INotifyPropertyChanged, IEditableObject, etc.) your presenter can make the UI that much simpler with less code. Some may say, databinding isn't an advantage - that's beside the point. Many of these interfaces don't make sense to web although it probably doesn't hurt it. I could create an adapter for the WinForms for databinding purposes. So I have another layer. The question is, is it worth the effort?

Gnarly

Answer 8

Ed Altorfer,

I'm a little confused by what you refer to as controller.

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).

But by your statements, it seems like controllers are what contains application logic (business logic?) and your models are simply data holders.

From what I understand, P stands for Presentation. P is concerned with presentation logic - how best to present the user with the underlying business information. The actual business logic/rules would be containe in the model layer. In fact, what you call controllers would also be part of the model layer - the M.

In any case, your example regarding the "demanding" boss seems like it's straight out of text book - we all know this. That's not what I am arguing.

Again, if P is for presentation, your WinForms and Web may have completely different flow for their presentation needs. Not to mention the console one for the batch app where you may not even need the P layer. Databinding makes WinForms UI layer so much simpler - the V - assuming databinding technology works as designed. Try comparing the sources of databinding vs. non-databinding apps. In non-databinding scenario, there are more moving parts that you have to manage yourself. You have more control but still you have to manage it. In my opinion, databinding matters to how I write the P.

I don't disagree that you CAN make one P layer work for all kinds of UIs but I am afraid, while doing so, you have to make a compromise on the least common denominator for all your UIs. And also that you might be pushing more of the presentation logic into the UI layer - which in turn makes unit testing more difficult.

I hope that clarified my original dilemma. I'm afraid I may be lacking the ability to express myself adequately...

Gnarly

Answer 9

You're doing a fine job of explaining yourself--no worries. :)

Be careful not to confuse application logic with business logic. Application logic is sometimes referred to as application process control, which is probably a more apt name for it. This is basically user actions and system responses. For example, Step 1: User logs in, Step 2: User clicks "Create New Invoice," Step 3: User submits basic information, Step 4: User adds line items, Step 5: User submits the invoice to the invoice database.

The steps I've outlined below are process control that applies to any UI you'd design for your invoice application. Business logic, on the other hand, is encapsulated in your models. P is for presentation, yes, but it is not for presentation logic. In most cases, P is going to refer to your client-facing content (e.g., ASPX, JSPX, Ruby on Rails views, etc.)--it is strictly markup. In other words, your controllers provide some behavior for your presentation layer.

Given these definitions, you can probably see how, if you created your controllers and models properly, they would be completely UI agnostic. You wouldn't have to cater to the lowest common denominator because they simply encapsulate your process logic and business logic, allowing your presentation layer to cater to the medium via which you're exposing that logic (e.g., the Internet, console, or desktop applications).

As a side note, sometimes controllers and models are actually exposed in some other abstracted way (like web services) so that you can have a bunch of UIs or web servers to balance some of your incoming traffic and you can still leverage the same back end.

Hope this helps a little?

Autochthonous

Answer 10

The reuseability afforded by the MVC design is not such that the same view/presenter can present the same model/controller to different outputs, but rather, different model/controller sets can be presented on a common view.

A system, as it matures, is likely to have need for several views: a Web interface, a desktop editor, an automated script API, and several different models: Billing for Customer A is order-by-order, but Customer B needs it Quarterly by customer department.

Tillandsia