Stupid Question 199: Do we need to decouple the view from logic (mv* patterns)?

[To celebrate my first year of programming I will ask a ‘stupid’ questions daily on my blog for a year, to make sure I learn at least 365 new things during my second year as a developer]

I’m still in London and met up with the brilliant developer Rob Ashton today and his friend Vicky (also a dev) for dinner and drinks with Daniel and Niclas (IT-pros). As always it didn’t take long before we started talking code, and we started talking about MV-something patterns. You know, MVP, MVC and MVVM. The last two are patterns I always use in one way or another, and to be honest I have used them because I feel convinced that the decoupling from the view is desirable. That’s what I’ve always heard. But is it? Does it make sense, always? Is it given that it is the way you should build your application?

Do we need to decouple the view from logic (mv* patterns)?

We did discussed this for at least an hour, and we discussed the idea of having a modularized application with bits that push to a piece if view (the view consisting of several bits) instead of the view pulling data from the view model. So instead of a layered application you would have a modularized application. What would be best and under which circumstances? Are the MV* patterns being overused as many developers overlook options convinced that this is the only way to go? While I still feel convinced, I still want to ask for your opinion.

I have come across situations where the view has to be, or at least seems to be, so dependent on the logic that a separation adds unnecessary complexity which might make the logic somehow loose its context. I’ve still forced in a separation, but now I’m questioning it. Do we need to separate the view from the logic? Always?

Please feel free to share articles, blog posts and comments, and I’ll do my best to sum it up.

Comments

Leave a comment below, or by email.

Herbert Sabanal

6/23/2013 6:40:14 PM

I do feel the need to separate the View and the logic. 
Primarily, the reason would be the testability. It would be hard to test Views with logic. Views should only be used to display data and state. I have used ASP.NET Webforms before and when I tried to get my hands dirty with MVC, I didn't look back.
Besides, if you use MVVM, you get View logic in the View Model with the testability still there.

Mark Jones

6/24/2013 12:33:27 AM

I write a lot of .Net Gadgeteer projects, which are hardware-based. If I want to write unit tests around the logic, I have to move it away from the "UI" (i.e. physical hardware).  I tend to use the MVP pattern to separate the UI from the logic, but only because there's no better pattern [that I know of].

Rob Ashton

6/24/2013 1:52:11 AM

For reference reading and material, (And it's rare that I agree with a PHP developer)

http://www.workingsoftware.com.au/page/Your_templating_engine_sucks_and_everything_you_have_ever_written_is_spaghetti_code_yes_you

My own slightly more focused opinion can be found here

http://codeofrob.com/entries/anti-templating-languages.html

A good paper on the idea of push-based templating can be found here:

http://www.perlmonks.org/?node_id=674225

Always good to be reading and having discussions like this :-)

Ash Tewari

6/25/2013 5:03:34 AM

My opinion is that view separation is not to be done for its own sake. There are benefits to be gained by view separation. But it is not an all-or-nothing proposition. For an application as a whole, view separation is desirable due to the advantages it brings to the table. However, I agree that achieving view separation for certain use-cases adds way too much complexity. These use-cases should be evaluated for cost-benefit balance. 
Here is something I wrote recently - Why you should use MVVM (even for small apps) -
http://blog.appliedis.com/2013/05/08/why-you-should-use-mvvm-for-small-apps/

Mike C

6/25/2013 8:52:15 AM

Separating the view from the business logic makes sense when you want to offer multiple views (web, app, phone) but only maintain one source of business logic.  The MV* patterns are also good in that they impose some logical ordering to your projects (controllers over here, model over there).  For these reasons, I'm in favor of MV* patterns.

That said, there's something to be said for the simplicity of putting the logic in the Button_Click event, especially for new developers as they start to learn the ropes.  (Let's get them writing apps and earning experience now, and we can introduce them to Async and better UX later.)

Claus Polanka

6/27/2013 3:52:49 AM

Hi Iris, thx for this great question. I think it doesn't matter which MV* pattern will be used as long you are able to test (Unit-Test) your logic. I like code which adheres to Michael Feather's rule to never place a test unfriendly feature (e.g. database access, file access, use of 3rd party libs, network access) within a test unfriendly construct (e.g. sealed methods, static methods, constructors, private methods, ...) or the short form: "Never hide a TUF within a TUC" ;-) This ensures that your code stays testable because if you can't test it, how do you know if it works ;-)
Cheers

Last modified on 2013-06-22