http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660I do so, but i wrote a post in my blog with an explanation on how to unit test it: [jfromaniello.blogspot.com/.../...-and-dynamic.html](http://jfromaniello.blogspot.com/2011/04/unit-tests-anonymous-types-and-dynamic.html) without mixing in the tests serialization concerns. http://ayende.com/4807/refactoring-toward-frictionless-odorless-code-the-case-for-the-view-model#comment11http://ayende.com/4807/refactoring-toward-frictionless-odorless-code-the-case-for-the-view-model#comment11Sun, 10 Apr 2011 23:32:11 GMT@naraga It'd be very unwise of me, advocating using implicit paradigm in all the cases ;-) What I meant, was rather sth like 20% coverage. http://ayende.com/4807/refactoring-toward-frictionless-odorless-code-the-case-for-the-view-model#comment10http://ayende.com/4807/refactoring-toward-frictionless-odorless-code-the-case-for-the-view-model#comment10Sun, 10 Apr 2011 20:55:31 GMT@Scooletz, yeah i was writing about credentials example mentioned by @wayne-o. http://ayende.com/4807/refactoring-toward-frictionless-odorless-code-the-case-for-the-view-model#comment9http://ayende.com/4807/refactoring-toward-frictionless-odorless-code-the-case-for-the-view-model#comment9Sun, 10 Apr 2011 20:15:11 GMT@Ayende, Even for trivial cases, when all but the proxy loaded data can be passed? I don't agree. Using convention by default, getting code explicit as you need to overwrite it (as you showed omitting Title property). @naraga There's no security hole in conventional json serialization for cases where you know, you can go with it. Security checks and so on can be applied to the actions as well. If you write about sending some passwords, etc. - be explicit then. http://ayende.com/4807/refactoring-toward-frictionless-odorless-code-the-case-for-the-view-model#comment8http://ayende.com/4807/refactoring-toward-frictionless-odorless-code-the-case-for-the-view-model#comment8Sun, 10 Apr 2011 19:46:21 GMT@Scooletz, never tried solution like automapper but doesnt it take you back? i mean when you decide for something like viewmodel you are telling that you want to be *explicit* about what is going to be send. the only problem you solve with implicit mapping is the lazyloading. in this article ayende is dealing only with the loading problem so it is appropriate to mention your way of mapping but in general you are getting exposed to all kind of aforementioned issues like security etc.... http://ayende.com/4807/refactoring-toward-frictionless-odorless-code-the-case-for-the-view-model#comment7http://ayende.com/4807/refactoring-toward-frictionless-odorless-code-the-case-for-the-view-model#comment7Sun, 10 Apr 2011 15:06:18 GMTThe only problem I've found so far with this is that if you are using an IoC container, such as Windsor, you cannot inject classes into your controller that have a dependency on ISession, such as the Rhino Security services. The session isn't opened until after the controller is instantiated so it fails. You could use a service locator pattern to get around that but that's quite an unpopular approach. You could also change the Rhino Security services to have a dependency on some sort of ISession provider, what do yo think? http://ayende.com/4807/refactoring-toward-frictionless-odorless-code-the-case-for-the-view-model#comment6http://ayende.com/4807/refactoring-toward-frictionless-odorless-code-the-case-for-the-view-model#comment6Sun, 10 Apr 2011 12:23:45 GMTScooletz, Yuck, that sounds like a recipe for disaster, to tell you the truth. http://ayende.com/4807/refactoring-toward-frictionless-odorless-code-the-case-for-the-view-model#comment5http://ayende.com/4807/refactoring-toward-frictionless-odorless-code-the-case-for-the-view-model#comment5Sun, 10 Apr 2011 10:03:52 GMT@Ayende, have you tried in any of your application implicit solution, by replacing the data of JsonResult in an action filter? I mean using sth like Automapper or your own convention. http://ayende.com/4807/refactoring-toward-frictionless-odorless-code-the-case-for-the-view-model#comment4http://ayende.com/4807/refactoring-toward-frictionless-odorless-code-the-case-for-the-view-model#comment4Sun, 10 Apr 2011 10:02:02 GMTI have to agree with wayne and I'll add that while performance (and bug-free software) is extremely important, security is more. lazy loading is only exposing a bigger problem with your architecture,. Let's say lazy loading worked perfectly and was blazingly fast. You still have a major problem here, as you're not explicilty controlling what your application exposes to the outside world, you expose information that should never get out of your system. So, it's true that there's a technical problem because of Lazy Loading, yet I wish you'd touch the bigger issue at hand. Looking at this in a OO sort of way, you're basically violating encapsulation. http://ayende.com/4807/refactoring-toward-frictionless-odorless-code-the-case-for-the-view-model#comment3http://ayende.com/4807/refactoring-toward-frictionless-odorless-code-the-case-for-the-view-model#comment3Sun, 10 Apr 2011 09:52:11 GMTAlso the amount of work needed for separate view models is very low. I usually reuse them as input parameters in post methods. http://ayende.com/4807/refactoring-toward-frictionless-odorless-code-the-case-for-the-view-model#comment2http://ayende.com/4807/refactoring-toward-frictionless-odorless-code-the-case-for-the-view-model#comment2Sun, 10 Apr 2011 09:42:57 GMTThe other reason to do this is security. Imagine doing: return Json(user, JsonRequestBehavior.AllowGet); Say helo to the users credentials - I'm not saying it's something most would do but this could easilly be a mistake made by some new bod on the project. Or perhaps a slip in concentration - but the result is the users credentials getting serialized. You want to control what gets sent down the wire and you want to minimise the risk of something bad happening. http://ayende.com/4807/refactoring-toward-frictionless-odorless-code-the-case-for-the-view-model#comment1http://ayende.com/4807/refactoring-toward-frictionless-odorless-code-the-case-for-the-view-model#comment1Sun, 10 Apr 2011 09:30:49 GMT