Timeline for Using business objects in view models
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 2, 2012 at 20:48 | comment | added | Michael Borgwardt | @Lucifer Sam: obviously we have very different concepts of what a view model is. Yours sounds very, very weird to me, like you're describing mainframe apps for dumb terminals, but certainly not modern web or fat client apps. | |
| Aug 2, 2012 at 20:43 | comment | added | Michael Borgwardt | @MattDavey: if you rename a property then with a separate view model you have to change the view as well (or whatever maps between domain and view model) and now have two different names for the same thing, which is certain to cause confusion. | |
| Aug 2, 2012 at 17:02 | comment | added | MattDavey | "If the domain model changes significantly , it's almost certain that the view will have to change anyway." - Agreed. But what about when you have a small change to the domain? With option one, every little change to the domain (even just renaming a property) requires a corresponding change to the view. This is also absolute poison for maintainability. | |
| Aug 2, 2012 at 16:22 | comment | added | Jeff Camera | I'm sorry but this is horrible advice for all but the most trivial of applications. View models don't have state. They are data transfer objects. What tab is selected is part of the STRUCTURE of the view and has NOTHING to do with the DATA in the view model what so ever. Maintenance isn't a nightmare if you structure your program properly and use something like Automapper to hydrate your view models. | |
| Aug 2, 2012 at 15:56 | comment | added | Martin Blore | YAGNI - the secret assassin of solving most software design problems. | |
| Aug 2, 2012 at 15:53 | history | answered | Michael Borgwardt | CC BY-SA 3.0 |