Timeline for Using business objects in view models
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 4, 2019 at 3:16 | comment | added | The_Sympathizer | So does this mean things like, say, formatting a timestamp for user display, should belong to the view layer, not the domain layer, and domain level objects should return only a raw, unformatted timestamp to the view objects and the latter are what should contain the formatter logic? | |
| Sep 7, 2017 at 2:51 | comment | added | Jeff | If you cannot have domain objects in a VM, then how would you represent something more complicated like an array of Orders? | |
| Dec 8, 2013 at 7:27 | comment | added | KingOfHypocrites | I like your answer but some thoughts... The view model doesn't necessarily change just because the model changes. Only if you were binding or using a specific property that changed would this be an issue since your reference is to the entire object. Having a reference to the domain object makes it easier to make changes and save it again. Your save methods are also dependent on the domain object so you then have to convert the view model back or have your business method setup to accept view models which isn't good either. I still think #2 makes most sense, but just by two cents. | |
| Aug 2, 2012 at 15:44 | comment | added | MattDavey | @AndyBursh yep that's correct - see this article, particularly the line "Robert C. Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to change." | |
| Aug 2, 2012 at 15:38 | comment | added | Andy Hunt | Am I correct in thinking that by "reason to change" you mean change in a maintenance sense, not change in an updating (eg ui event) sense? | |
| Aug 2, 2012 at 15:33 | history | edited | MattDavey | CC BY-SA 3.0 | added 190 characters in body |
| Aug 2, 2012 at 15:27 | history | answered | MattDavey | CC BY-SA 3.0 |