does it make sense to use KnockoutJS Viewmodels in combination with ASP.NET MVC3 or 4? Because it is not very DRY, isn’t it? I have to write models for EF, Viewmodels for the MVC Views and Viewmodels for Knockout… and i lose a lot of magic. Automatic client-side validations for example.
Does it make sense to use MVC at all if one sticks with the MVVM Pattern?
This may be an unpopular answer, but I don’t use
ko.mappingto translate my C# POCOs into JS viewmodels. Two reasons, really.The first is a lack of control. ko.mapping will turn everything into an observable if you let it. This can result in a lot of overhead for fields that just don’t need to be observable.
Second reason is about extensibility. Sure, ko.mapping may translate my C# POCOS into JS objects with observable properties. That’s fine until the point you want a JS method, which at some point, you invariably will.
In a previous project, I was actually adding extra methods to ko.mapped objects programmatically. At that point, I questioned whether ko.mapping was really creating more problems than it solves.
I take on board your DRY concerns, but then, I have different domain-focused versions of my POCOs anyway. For example a
MyProject.Users.Userobject served up by a UserController might be very different from aMyProject.Articles.User. The user in the Users namespace might contain a lot of stuff that is related to user administration. The User object in the Articles namespace might just be a simple lookup to indicate the author of an article. I don’t see this approach as a violation of the DRY principle; rather a means of looking at the same concept in two different ways.It’s more upfront work, but it means I have problem-specific representations of User that do not pollute each others’ implementations.
And so it is with Javascript view models. They are not C# POCOs. They’re a specific take on a concept suited to a specific purpose; holding and operating on client side data. While
ko.mappingwill initially give you what seems to be a productivity boost, I think it is better to hand-craft specific view-models designed for the client.btw, I use exactly the same MVC3/KnockoutJS strategy as yourself.