That dreaded M in ASP.NET MVC

When it comes to working with Models in MVC, I’ve tried many approaches, some good, others not so much. I’ve ended up settling on ViewModels, whereby the Model I submit is dictated by the View I’m working with. This allows me the flexibility of displaying or gathering only the information I need. It also allows me to provide additional information on the view that isn’t necessarily required by my domain.

It works, but it also adds a lot of friction. Be it mapping, be it validation, it’s continuously repeating same processes over and over again. Even automating some of this still requires constant set up. Every time I work with ASP.NET MVC, I dread having to deal with all this. Way too much friction.

I’ve often wondered whether I’m overly complicating myself by trying to add so much flexibility. I mean if the Rails guys can work with ActiveRecord, why can’t I? Granted that maybe much of the drawbacks of ActiveRecord can be remedied in some way in Rails because of Ruby being a dynamic language and allowing for things such as Mixins, but still, what about the other stuff? The mapping to an actual domain model. What happens when they need a list of countries? What happens when they have to update only 2 out of 7 fields of their domain model?

I decided to ask Shay how he works. As a guy who works with both ASP.NET MVC and Rails, and has written a book on IronRuby, I thought he’d be a good candidate. Plus, he’s a nice guy.

I have to say I wasn’t really surprised by his answer. He binds directly to his Domain Model in ASP.NET MVC. I asked how he dealt with additional info: Html Helpers. I asked how he solved partial updates: In the controller. Although, not surprising, it was interesting. As a guy that’s worked heavily in Rails, he seems to cope fine with this approach in C#.

So again I wonder, am I focusing on too much flexibility? I decided to ask others by running a quick survey on Twitter asking how people worked with M in MVC.

1. First the disqualifying question. Are you using Strongly-Typed views?

image

98% voted they are. I’m guessing more than 2 people were not, but since the Survey was focused on strongly-typed views, they probably didn’t take part.

2. Now the question to see if I am the odd one out using ViewModels

image

Apparently not. 78% of people use ViewModels.

3. The next question was how one deals with only partially updating some fields of a Domain Model if binding directly to them.

image

4. What about that damn list of countries?

image

(I’ve actually found another way to solve this problem, partially based on conventions, and we might even build it in to AutoReST. But that’s for another post).

5. Key question the following. Mappings (read friction). If you use ViewModels, do you manually map information or use something like AutoMapper?

image

Surprised by the number of people doing manual mapping. You would think that if AutoMapper’s only responsibility is to do mapping for you, why not use it? Could it be again the same issue? Too much friction to setup? NuGet to the rescue? Too much ceremony?

6. Here’s another one. Validation.

SNAGHTMLaa90b6d

So pretty much everyone (79%), some way or other has to deal with decorating their models with attributes.

7. Finally, I was curious how people felt in general with the development process. Did they also encounter friction?

image

Not surprisingly, 70% find some level of friction in doing web development.

Conclusions

First off, this is not a stab at ASP.NET MVC. If you take it like that, you’re barking up the wrong tree. I’m sure in one way or another, any platform or language has a certain level of friction when it comes to developing applications. No, this is more of a self-stabbing.

I also agree that on the whole, there’s too much friction. However, I’m not sure how much of that friction is caused by the platform vs the mentality of us developers to think big and try to build in so much unneeded flexibility. Are we really applying YAGNI? Are we really applying KISS? Maybe adding so much flexibility in terms of ViewModels because, and I quote, “when dealing with complex scenarios, simple approaches fall apart” only actually solve a 5% edge case that could be remedied in a different way.

Maybe we should stop being afraid of trying to be too strict and not flexible enough. Maybe we should take the concept of conventions more seriously than just what folders our Views, Controllers and Models reside in. Maybe we should push conventions to the limit and see if we actually reduce this friction.

And that’s the next journey I’m going to embark on. It might be time to drop the ViewModel, it might not be. What I do know is that writing good software shouldn’t be so complex.


Posted 01-02-2011 5:50 PM by Hadi Hariri

[Advertisement]

Comments

Alex wrote re: That dreaded M in ASP.NET MVC
on 01-02-2011 6:21 PM

I separate the domain and view models as I like the separation it provides.  However, I go crazy when I need to do things like duplicate my validation rules.  So instead i have replaced the validation layer in MVC with one that does the following:

1) looks for specified rules on the view model (usually validations where there is no map to the domain model)

2) an attribute is added to the viewmodel that states the domain model(s) that the viewmodel uses.  This attribute directs the validation layer to the correct classes for further property validation rules (correct datatype, string length, regex validation, etc.)  This allows centralized validation.

3) finally, the validation layer looks at the domain classes for attributes that indicate domain level validation - which properties must be unique, etc.

This approach also requires a lot of convention since the names of properties on the viewmodel and domain model must match up.  It takes a lot of work to get it right, but it really makes a lot more sense to me.

Mappings are always handled in the service layer - the controller never does anything important, it simply sends data to the service layer and that layer determines what to do with the data - call to a database, a web service, etc.  The rule is that only viewmodels can be passed in or out of the service layer methods while the methods themselves do the mapping and hand off a "clean" domain model to the repositories.

Nick wrote re: That dreaded M in ASP.NET MVC
on 01-02-2011 7:50 PM

If you're a smart coder then you earn your money by finding the best way to do things. Who would want a job that was so easy?

I like choices, I like creativity and I love these kind of problems and seeing how different people solve the problems in unique ways.

Maybe if this stresses you out so much, then is it really worth it? Is this really something you enjoy?

Good blog post backed up with some good stats though.

Hadi Hariri wrote re: That dreaded M in ASP.NET MVC
on 01-03-2011 2:12 AM

@Nick

This is about reducing the friction. It's about spending time on what really matters. It's about finding better ways to solve problems. It's not about stress.

Koen wrote re: That dreaded M in ASP.NET MVC
on 01-03-2011 6:07 AM

Very interesting post;

The same questions arise for WPF / Silverlight applications, using some variant of an MVVM approach.

Does the ViewModel directly uses the BusinessModel?

Or does it just exposes properties to which the View binds?

As mentioned here, both approaches come with their pro's and con's. Our company choose for an "it depends" approach, and tends to directly use the BusinessModel for master-data CRUD scenario's, and use pure ViewModel style for non CRUD scenario's.

The motivation behind this decision is:

-  master-data CRUD screens, mostly influence an entire BusinessObject

- master-data CRUD screens are "simple" input screens; using the BusinessObjects directly here allows for faster development of those "simple" input screens.

- non-master-data CRUD screens tend to combine data from multiple BusinessObjects. The past proved us that working with BusinessObjects directly here, got us into trouble. So we use ViewModels, very specific for a certains View, for those scenarios.

Regards,

Koen

Harry wrote re: That dreaded M in ASP.NET MVC
on 01-03-2011 3:09 PM

Good post and excellent question about the friction. Any framework promise less friction down the road requires you to overcome the initial friction. That's part of learning the framework and learning new libraries ...

Steve wrote re: That dreaded M in ASP.NET MVC
on 01-03-2011 3:23 PM

Quite contrary to your comments, I'm surprised Automapper has a near 50% adoption rate.

That is insanely high for an OSS project within the Microsoft Space.  That, or I wonder if it speaks to the people who are doing ASP.NET MVC work v. ASP.NET Webforms?

Nick wrote re: That dreaded M in ASP.NET MVC
on 01-03-2011 3:50 PM

@Hadi Harri

Sorry

Andreas wrote re: That dreaded M in ASP.NET MVC
on 01-04-2011 4:08 AM

@alex do you have a blog post on your setup somewhere?

Guy wrote re: That dreaded M in ASP.NET MVC
on 01-04-2011 4:13 PM

Good article I ask myself the same questions everytime. I lean towards the opinion that it mybe more friction upfront, but during support and feature enhancements it is easier. I also find that if you have multiple front ends besides just the web you would have different ViewModels for different platforms, but the domain would stay the same. For example an application with a WP7 view and a Web view.

Shane wrote re: That dreaded M in ASP.NET MVC
on 01-04-2011 8:17 PM

Too much friction??  I don't get it.  If by 'friction' you mean you still have to write code, yeah I sort of agree that there is still some friction when using ViewModel's, AutoMapper, and strongly-typed views.  This is still 1 billion times better than web forms because its much more testable.  It took me a while to get that and see through the pain of setting up mappings and adding validation attributes, but its well worth it when you can test so much more of your code.

I appreciate the collection of stats, it'd be nice to see how many people are using TDD or have any testing at all.

Hadi Hariri wrote re: That dreaded M in ASP.NET MVC
on 01-05-2011 1:48 AM

@Shane,

Of course it's better than WebForms, that's why I'm been developing with MVC since Preview 1, but that still doesn't mean we can't find better ways to do things.

Steve wrote re: That dreaded M in ASP.NET MVC
on 01-05-2011 8:32 AM

@Shane,

"It took me a while to get that and see through the pain of setting up mappings and adding validation attributes"

I think you just defined friction.

Of course MVC is better than Web Forms, that's like comparing a Porsche to a broken down Pinto...what Hadi is talking about is turning that Porsche into a Ferrari.

beto wrote re: That dreaded M in ASP.NET MVC
on 01-05-2011 11:24 PM

I'm interested on how you think you got an answer for question number #4.  Looking forward to this blog post.

depaulo wrote re: That dreaded M in ASP.NET MVC
on 01-06-2011 11:42 AM

We use a ViewModel which contains whatever 'resources the view needs and may contain one or more FormModel dto's. It is the form dto which gets bound to in the action.  ie the country list can go in the viewmodel but the property is not in the dto that goes to the action

gOODiDEA.NET wrote Cheatsheet: 2011 01.01 ~ 01.10
on 01-09-2011 8:04 PM

.NET Writing a Compiler in C#: C Code Generation, Part 1 That dreaded M in ASP.NET MVC A .NET Project

social bookmark submission wrote re: That dreaded M in ASP.NET MVC
on 01-18-2013 6:12 AM

TCIt2t I truly appreciate this blog. Will read on...

weight loss pills wrote re: That dreaded M in ASP.NET MVC
on 02-01-2013 12:50 AM

IFqyAd I really liked your post. Fantastic.

http://bestmedicineonline.info wrote re: That dreaded M in ASP.NET MVC
on 02-15-2013 5:28 PM

eao4cw I think this is a real great article post.Really thank you! Cool.

buy clomid wrote re: That dreaded M in ASP.NET MVC
on 02-28-2013 3:48 PM

sXcSu4 I truly appreciate this blog. Cool.

stoners wrote re: That dreaded M in ASP.NET MVC
on 04-06-2013 3:35 PM

Say, you got a nice blog. Much obliged.

cheap social bookmarks wrote re: That dreaded M in ASP.NET MVC
on 06-19-2013 6:12 PM

sPVuWm Great, thanks for sharing this blog.Thanks Again. Will read on...

cheap bookmarks wrote re: That dreaded M in ASP.NET MVC
on 06-21-2013 10:59 AM

WgYTNF I appreciate you sharing this blog.Much thanks again. Fantastic.

cool news wrote re: That dreaded M in ASP.NET MVC
on 07-09-2013 7:26 AM

dC9fKX This is one awesome article. Keep writing.

buy viagra online cheap wrote re: That dreaded M in ASP.NET MVC
on 07-23-2013 2:07 PM

Thank you ever so for you blog article.Much thanks again. Will read on...

this site wrote re: That dreaded M in ASP.NET MVC
on 07-24-2013 3:42 PM

wow, awesome article post. Cool.

hot news wrote re: That dreaded M in ASP.NET MVC
on 07-26-2013 4:39 AM

xEAS5L Thanks again for the post.Really looking forward to read more. Fantastic.

buy social bookmarks wrote re: That dreaded M in ASP.NET MVC
on 07-28-2013 12:05 PM

oUGJuV Thanks so much for the article. Great.

amazing news wrote re: That dreaded M in ASP.NET MVC
on 08-02-2013 12:37 PM

Appreciate you sharing, great article.Really looking forward to read more. Much obliged.

best news wrote re: That dreaded M in ASP.NET MVC
on 08-02-2013 5:58 PM

AmCm2J Say, you got a nice article post.Much thanks again. Really Great.

amazing news wrote re: That dreaded M in ASP.NET MVC
on 08-03-2013 5:48 PM

nP0cze Thanks so much for the article.Really thank you! Awesome.

great link buildng wrote re: That dreaded M in ASP.NET MVC
on 08-19-2013 1:21 PM

wgVDNf I cannot thank you enough for the blog.Much thanks again. Fantastic.

great link buildng wrote re: That dreaded M in ASP.NET MVC
on 08-19-2013 11:31 PM

rbtVzo Thanks a lot for the article post.Much thanks again. Want more.

great link buildng wrote re: That dreaded M in ASP.NET MVC
on 08-22-2013 3:32 AM

qgLML3 Thank you ever so for you blog post. Really Cool.

seo service wrote re: That dreaded M in ASP.NET MVC
on 09-07-2013 2:50 AM

XlMKK8 A big thank you for your blog post.Really thank you! Great.

only for 5 dollars wrote re: That dreaded M in ASP.NET MVC
on 09-13-2013 11:23 AM

Jnak94 I am so grateful for your post.Really thank you! Cool.

awesome link building wrote re: That dreaded M in ASP.NET MVC
on 09-24-2013 8:56 AM

4NAwCA Very informative blog article.Really looking forward to read more. Awesome.

best linkbuilding wrote re: That dreaded M in ASP.NET MVC
on 09-30-2013 9:26 PM

IuVKcW I really like and appreciate your blog article.Much thanks again.

check out these guys! wrote re: That dreaded M in ASP.NET MVC
on 10-15-2013 11:51 PM

8pbXgU Thanks for the article post.Thanks Again. Fantastic.

top seo guys wrote re: That dreaded M in ASP.NET MVC
on 10-24-2013 3:18 AM

ol8JMc Thanks for the blog post.Thanks Again. Awesome.

smashing top seo wrote re: That dreaded M in ASP.NET MVC
on 10-31-2013 5:43 AM

qJTsTD I truly appreciate this blog.Thanks Again. Really Great.

high quality backlinks wrote re: That dreaded M in ASP.NET MVC
on 07-18-2014 7:30 AM

lOFiiD Very informative article.Much thanks again. Really Cool.

crorkz matz wrote re: That dreaded M in ASP.NET MVC
on 08-06-2014 6:55 AM

uzrDM4 Wow, great article post.Much thanks again.

crorkz wrote re: That dreaded M in ASP.NET MVC
on 10-20-2014 11:05 PM

thmrTI Very nice info and right to the point. I don't know if this is truly the best place to ask but do you people have any ideea where to get some professional writers? Thank you :)

Add a Comment

(required)  
(optional)
(required)  
Remember Me?

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)