http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Another advantage of splitting models is that you then don't need to map from your domain model to your view model (and vice versa). Why hydrate domain objects in the first place if you can create simpler objects in the first place? http://ayende.com/4375/encapsulation-is-the-enemy-of-the-user-interface#comment6http://ayende.com/4375/encapsulation-is-the-enemy-of-the-user-interface#comment6Tue, 26 Jan 2010 11:23:35 GMTYes, darned users, always want to interfere with my beautiful coding with silly UIs, Command Lines and *gasp* API calls. http://ayende.com/4375/encapsulation-is-the-enemy-of-the-user-interface#comment5http://ayende.com/4375/encapsulation-is-the-enemy-of-the-user-interface#comment5Tue, 26 Jan 2010 08:37:48 GMTDepending on what you're writing, avoiding DTOs can be wrought with adding a whole level of complexity integrated in the code that matters. Data-binding is the rage. Restricting actions available to users is easy; restricting views available to users is easy; but restricting specific details of data transferred to those common views... That's where things can go pear-shaped. I hate the thought of introducing code into views that essentially says "oh, I just won't show that." I'm not sure I'd go so far as to introduce a separate models for view vs. update. I do like to define DTOs specific not only to views, but to things like user roles. IMO a view needs to remain ignorant of the business entities, but I guess that's why I tend to think more MVP/MVC rather than MVVM. http://ayende.com/4375/encapsulation-is-the-enemy-of-the-user-interface#comment4http://ayende.com/4375/encapsulation-is-the-enemy-of-the-user-interface#comment4Tue, 26 Jan 2010 05:39:14 GMTWho are you agreeing with, Rafal? :) Yes, development is much more productive after understanding CQ(R)S. I love mixing them together like an alcoholic drink. http://ayende.com/4375/encapsulation-is-the-enemy-of-the-user-interface#comment3http://ayende.com/4375/encapsulation-is-the-enemy-of-the-user-interface#comment3Mon, 25 Jan 2010 18:28:27 GMTAgreed. Artificial separation of the 'model' and 'view model' leads to duplication of logic and lots of boilerplate code to generate data transport objects. It's much better to allow the use of ORM-generated DAL in views + some smart ambient session management. http://ayende.com/4375/encapsulation-is-the-enemy-of-the-user-interface#comment2http://ayende.com/4375/encapsulation-is-the-enemy-of-the-user-interface#comment2Mon, 25 Jan 2010 14:23:30 GMTIMO don't mix up CQS with CQRS. they are two vastly different creatures. CQRS is Greg Youngs idea with a command model and a query model where you can have queries for a certain gui. CQS intends to make it possible to make pre/post/invariant checks in DBC without changing state and thus breaking already evaluated conditions. There may be commands and queries in both cases, but the problems and contexts are not the same. http://ayende.com/4375/encapsulation-is-the-enemy-of-the-user-interface#comment1http://ayende.com/4375/encapsulation-is-the-enemy-of-the-user-interface#comment1Mon, 25 Jan 2010 10:58:41 GMT