![[ERR!]](https://www.gravatar.com/avatar/94d1b9d6eed962641a26a95c11d9cb62?d=identicon&s=40)
367 Views
Working on a new ASP.NET MVC side-project, I have the luxury to experiment with new technologies, but also with different patterns and naming conventions. Something which bugged me in a previous project was that we made our service layer return viewmodels. It worked rather well because the service layer in our MVC project was just another layer between the real domain services - where most of its work was creating viewmodels from domain objects or translating viewmodels into domain objects, so they c...
3 comments
dpeterson
10/13/2011 9:46:09 AM
An interesting concept, it's sort of akin to the DataMapper pattern in that your viewmodels are acting as DTO's would in that pattern. I think it's a valid pattern, though I admittedly don't know _a ton_ about ASP.NET MVC. As an additional pattern for working with a project based on the MVC pattern, I think it fits nicely. I think it's more about *having* that particular layer of abstraction, rather than about *what* you're abstracting...if that makes any sense at all ;-)
vijayst
10/13/2011 12:08:45 PM
The Automapper will work for MVC business applications. But, if you take a complex application hosted on the internet like say Twitter, having a mapper may not work. A Twitter is a single-page application at its core. In the Microsoft stack, a combination of MVC, jQuery can do Twitter like stuff. But the ViewModel design gets really complex.
bradygaster
10/13/2011 3:00:23 PM
This is great. It sort of reminds me of a set of extension methods I wrote, which also use Extension Methods, to convert my NHibernate data entities into ViewModels using generics and AutoMapper.