Let's see What UI Patterns have to say about themselves

: Welcome Mr. Smart UI Pattern. Our developer friends want you to introduce yourself and justify the claim for being ‘Smart’.

: Mr. Developer, you can never shun your habit of forgetting the ‘Name’ of your own creation. Almost all programmers (including you) have created smart UI application at some point of time. I am very simple to start with. Developer can easily start by dragging UI components (like button, textbox etc.) on design surface. These UI component emit event handling code (like button click, mouse move etc.). Developer adds code to these event handlers. In doing this, he ends up with a monolithic application. The code that handles the user interface and the business is all mixed together with no separation of concerns at all. In short, when you write all the logic (UI, Presentation, business and domain) in code behind file, you are implementing Smart UI Pattern. And because my user interface knows everything, people call me smart.

: Ohk. But if you see beyond your nose, you will admit that maintainability and extensibility is going to be a problem while implementing you. Keeping the domain logic and business logic code in with the user interface can lead to code duplication. In a complex application it can be almost impossible to add a new feature without breaking an existing one. And what about writing test cases. I am afraid we cannot write test cases for user interface (without simulating user interaction). Do you know what I mean?

: Yup, I know. Now a day I am under fire for not being up to scratch in this regard. People abuse me a lot. Main idea of my existence was rapid development. Developers can easily develop a small application/ POC with in no time. But I should not be used in real time application.

: I know. So you too feel that some new patterns are the need of the hour to make things hum. So, to fill this slot, we have some new patterns. Please welcome MVC/MVP.

: Hi buddies! Resonating with our Developer friend, we too agree the whole idea of our existence is to strip off code from UI and make UI as dumb as possible.

: I can’t buy this. Why are you so much concerned making UI dumb? What is the problem if UI is in saddle of some business algorithm?

: You Developers knock down your patience quite avidly. We were getting into it. Issue with a thick UI is, you cannot test UI. It is very hard (and sometimes impossible) to write unit test cases for UI. So it is better to have as little code as possible. UI should only have UI logic (code that is dealing with rendering). If we keep all the code in user interface, we break Separation of concern and open-closed principle.

: Hmm. got the hang of it now. But we are building application for a long time and I personally never used you and never faced much issue. I have never been asked to write Unit test cases. In fact, in current project as well, client has not asked us for writing unit test.

: What if client asks later (after current phase). Would you tell your client that your code is not ready for unit test cases and you will have to change architecture to do that? What do you think, can you justify ‘Why have you not written code that support automation testing’. I am afraid you can’t.

: Hmm. That’s a point. Even if we are not writing unit test cases, code should be ready for it. But one of my friends writes unit test cases as well and he is not using MVC/MVP.

: We never said that we are the only one which helps in getting rid of all the issues of Smart UI pattern. Our other pals are there too. Like PM (presentation pattern), MVVM (ModelView View Model Pattern – specially designed for applications that support binding like WPF, Silverlight).

: Sorry to intervene you people, but one more friend of mine can help you achieve the same. It is ‘n tier architecture’, where you can achieve the separation of concern by creating different layers/tiers.

: True. N tier/layer architecture can also be used to overcome the limitation smart UI application have but even that pattern (n tier architecture pattern) is not 100% unit testable. Since nothing is imposed on developer they write lots of code in code behind file to map data coming from façade to UI component and vice versa. This code cannot be tested. MVC/MVP can be used to overcome this limitation.

: Great, Now things are getting interesting. I have few more questions. Before this interview session, I too spent many hours on internet. But soon I realized that I had been banging my head on brick wall as the topic is ambiguous enough to boggle anyone. The more I was reading about these UI Pattern (MVC, MVP, MVVM) more I was getting confused. And not only me, see what Martin Fowler has to say about MVC.

Different people reading about MVC in different places take different ideas from it and describe these as ‘MVC’. If this doesn’t cause enough confusion you then get the effect of misunderstandings of MVC that develop through a system of Chinese whispers. … Martin Fowler

So, to clear the air, let’s start with MVC first. If I am not wrong you’re the eldest among other UI Patterns.

: Singing in your tunes, let me introduce myself in the words of Martin Fowler only.

“Probably the widest quoted pattern in UI development is Model View Controller (MVC) – it’s also the most misquoted. I’ve lost count of the times I’ve seen something described as MVC which turned out to be nothing like it. Frankly a lot of the reason for this is that parts of classic MVC don’t really make sense for rich clients these days”

: Ha ha ha… What a glowing introduction! On serious note, could you please let us know who you are and what you do?

: As you know all of us (UI patterns) move code away from code behind so that it can be made more testable. I do the same by using three components i.e. Model, View and Controller.

Model: It could be Domain object (class that typically represents a table in database. For ex, Order, Product etc.) Or a plain DTO (data transfer object).

View: it is the UI component. For instance, in web application, it is made of html.
Controller: This is what has replaced the code behind file. It is a plain class file. When user take any action on UI, instead of handling that event in code behind, Controller’s class method gets invoked. For instance, if user clicks on Submit button, hit goes to one of the controller’s method that can save the data and in return can change the user’s view by returning a different view.

: So what happens to code behind?

: I cannot exist with code behind file. If there is a code behind file you cannot implement me. For instance, you cannot use me in windows application/ asp.net applications (which has .aspx and .aspx.cs file). In these cases MVP (MVC variant) can be used. But some crazy people still call it MVC. Don’t know why?
There is a simple theory, user action should invoke Controller method, it should not he handled by UI component (code behind for instance). There are few developers (who have not worked with me) find it hard to digest that UI can be built without attaching event handler in code behind. (These are those developers who have only worked on Asp.net or windows form only). But this is very much possible in many technologies. For instance on html, you can create hyper link (rather than normal button) and set her to MVC’s controller method. Same can be achieved in xaml as well.

: One simple question. Are you in the order of the day now?

: Yes, very much. In fact Microsoft has specially designed a framework Asp.net MVC which works on my theory. In fact I am very much suited for web development.

: MVP, your turn.

: As MVC just said that it cannot be used with normal form-control/ Smart UI with code behind files (with event handler), I came as a rescue there. I am specially designed for these kinds of applications. I am a derivative of MVC itself. But I am not rigid like MVC and do not expect people to change their framework altogether. I comprehend that if they are comfortable with UI control and their event handler, let them use this. They can still move presentation logic from code behind to some other normal class. I have three components.

Model: Same as it is in MVC. It could be Domain object (class that typically represent a table in database. For ex, Order, Product etc.) Or a plain DTO (data transfer object).

View: Same as MVC. It is the UI component. For instance, in web application, it is made of html.

Presenter: This is what is changed from MVC. When user takes some action, event handler in code behind gets invoked, but instead of taking any action, it passes that to me. I am a simple class file which has many methods which ultimately serve user response. It updates the view with new information. I can be easily implemented by introducing one presenter class per code behind.

Martin Fowler thoughts on me “To approach MVP I find it helpful to think about a significant mismatch between two strands of UI thinking. On the one hand is the Forms and Controller architecture which was mainstream approach to UI design, on the other is MVC and its derivatives. The Forms and Controls model provides a design that is easy to understand and makes a good separation between reusable widgets and application specific code. What it lacks and MVC has so strongly, is Separated Presentation and indeed the context of programming using a Domain Model. I see MVP as a step towards uniting these streams, trying to take the best from each.”

: Thank you very much UI Patterns. This session was really an eye opening (for me at least ). I certainly knew that keeping all kind of code in code behind is a bad practice. And I always tried to write minimum code, but I admit that I wrote presentation logic there (since I did not have any choice).

But I am amazed to know that I can go one step ahead and move the presentation logic from UI to Presenter class (using MVP).
And if it is a web App, I can use MVC to get rid of code behind file altogether. That is really cool.
Thank you again.
I hope to see your pals (Presentation Model and MVVM) someday. Take Care