Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. WPF
  4. MVVM question: hierarchical model representation

MVVM question: hierarchical model representation

Scheduled Pinned Locked Moved WPF
questionwpfarchitecturetutorialannouncement
19 Posts 4 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • M Offline
    M Offline
    Member 1033907
    wrote on last edited by
    #1

    This one will be easy, I guess. Suppose I have a model class, for example Day, with its properties. Then I have DayViewModel, which wraps the Day for viewing, presents some other properties which are not present in the model class (like TimeOfSunset which can be computed, whatever, it's an example). Then I have Week class, which is a collection of Day objects + additional properties. Then again, WeekViewModel which wraps Week for viewing. I am not doing this automatically - one VM class for each M class, I really need to show Days (in a list maybe), hence the DayViewModel, and I want to show and interact with Weeks, hence the WeekViewModel. Now to the question. The Week class must include some property like List<Day> Days; which will be populated when the Week is loaded from the data store. But WeekViewModel requires something more like ObservableCollection<DayViewModel>. Now this is awkward, I already have one collection and I need to create another with the same physical data, just to change Day to DayViewModel and List to ObservableCollection. I could live with that but it gets worse. Whenever the WeekViewModel's ObservableCollection gets changed, I must take care to change the Week's List accordingly so that when I save the model classes to the data store, I am sure to have the most recent version. What is the common way to deal with this simple scenario? I believe that one of the benefits of MVVM is the fact, that several ViewModels can work with one Model just like several Views can work with one ViewModel (correct me if I am wrong). Following this principle, I can't simply use ObservableCollection<DayViewModel> directly in the Week (model) class, because that would tie the Model with one particular ViewModel. So, is there a better way around this than the one I outlined? I'll be happy to hear your suggestions, H.

    A L S 3 Replies Last reply
    0
    • M Member 1033907

      This one will be easy, I guess. Suppose I have a model class, for example Day, with its properties. Then I have DayViewModel, which wraps the Day for viewing, presents some other properties which are not present in the model class (like TimeOfSunset which can be computed, whatever, it's an example). Then I have Week class, which is a collection of Day objects + additional properties. Then again, WeekViewModel which wraps Week for viewing. I am not doing this automatically - one VM class for each M class, I really need to show Days (in a list maybe), hence the DayViewModel, and I want to show and interact with Weeks, hence the WeekViewModel. Now to the question. The Week class must include some property like List<Day> Days; which will be populated when the Week is loaded from the data store. But WeekViewModel requires something more like ObservableCollection<DayViewModel>. Now this is awkward, I already have one collection and I need to create another with the same physical data, just to change Day to DayViewModel and List to ObservableCollection. I could live with that but it gets worse. Whenever the WeekViewModel's ObservableCollection gets changed, I must take care to change the Week's List accordingly so that when I save the model classes to the data store, I am sure to have the most recent version. What is the common way to deal with this simple scenario? I believe that one of the benefits of MVVM is the fact, that several ViewModels can work with one Model just like several Views can work with one ViewModel (correct me if I am wrong). Following this principle, I can't simply use ObservableCollection<DayViewModel> directly in the Week (model) class, because that would tie the Model with one particular ViewModel. So, is there a better way around this than the one I outlined? I'll be happy to hear your suggestions, H.

      A Offline
      A Offline
      Alisaunder
      wrote on last edited by
      #2

      What you could do is something along the lines of

      DateViewModel(string Week, ObservableCollection Days)

      Making DateViewModel a class. I believe this would give you the functionality you are looking for. Or even possibly

      DateViewModel(ObservableCollection Week, ObservableCollection Days)

      M 1 Reply Last reply
      0
      • A Alisaunder

        What you could do is something along the lines of

        DateViewModel(string Week, ObservableCollection Days)

        Making DateViewModel a class. I believe this would give you the functionality you are looking for. Or even possibly

        DateViewModel(ObservableCollection Week, ObservableCollection Days)

        M Offline
        M Offline
        Member 1033907
        wrote on last edited by
        #3

        I see I didn't express myself clearly. It is not really a functionality I am looking for, more like advice on how to deal with the given scenario using MVVM. If I ditch MVVM, I am ok. Another approach to explaining the question: how to work with two-layer model data in MVVM framework. As an abstract example - consider a SubItem class (model) and associated SubItemViewModel, then I have Item class (model; containing a collection of SubItems) and associated ItemViewModel. The application works with a collection of Items (we may call this application-level class SuperItemViewModel). Like I explained in the original post, the model classes consist of ordinary collections of another model classes while the view-model classes contain observable collections of associated view-model classes (this is how I understand MVVM, which may be wrong). My question is, how to best plug these M and VM classes together while maintaining sufficient separability. That is, in the imaginary Item model class I could directly use ObservableCollection of SubItemViewModels but this, in my understanding, has no place in model classes, which are supposed to be unaware of view-models. To say it most generally, I think I understand the V-VM part but I don't really get the M-VM part. Hope I made myself clearer. If not, I may give up this thread and MVVM altogether:-) Thanks for any suggestions.

        1 Reply Last reply
        0
        • M Member 1033907

          This one will be easy, I guess. Suppose I have a model class, for example Day, with its properties. Then I have DayViewModel, which wraps the Day for viewing, presents some other properties which are not present in the model class (like TimeOfSunset which can be computed, whatever, it's an example). Then I have Week class, which is a collection of Day objects + additional properties. Then again, WeekViewModel which wraps Week for viewing. I am not doing this automatically - one VM class for each M class, I really need to show Days (in a list maybe), hence the DayViewModel, and I want to show and interact with Weeks, hence the WeekViewModel. Now to the question. The Week class must include some property like List<Day> Days; which will be populated when the Week is loaded from the data store. But WeekViewModel requires something more like ObservableCollection<DayViewModel>. Now this is awkward, I already have one collection and I need to create another with the same physical data, just to change Day to DayViewModel and List to ObservableCollection. I could live with that but it gets worse. Whenever the WeekViewModel's ObservableCollection gets changed, I must take care to change the Week's List accordingly so that when I save the model classes to the data store, I am sure to have the most recent version. What is the common way to deal with this simple scenario? I believe that one of the benefits of MVVM is the fact, that several ViewModels can work with one Model just like several Views can work with one ViewModel (correct me if I am wrong). Following this principle, I can't simply use ObservableCollection<DayViewModel> directly in the Week (model) class, because that would tie the Model with one particular ViewModel. So, is there a better way around this than the one I outlined? I'll be happy to hear your suggestions, H.

          L Offline
          L Offline
          Lost User
          wrote on last edited by
          #4

          You can use factories. So you will have a WeekVMFactory and a DayVMFactory. Factories basically have a "Build" method that returns you an instance of the object you want. In your case you would like pass it the Model object. Some factories may get IDs and then use DataAccess layers to fetch the needed data and build up the VM (no actual 'model' object exists, other that in the Data warehouse). So where ever you need your WeekVM (lets just say in the MonthVM) you inject the factory. IDayVMFactory dayFactory. You can do this via construction.

          for(int i=0; i < weeksNeeded; i++)
          {
          Weeks.Add(_weekFactory.Build(_dayFactory, i); //Pass i so we know what week it is.... Like an idea or something
          }

          Then in the weekVM constructor it is doing something along the same lines. At first this may seem like overkill, but there are numerous good reasons for this. Take a look at Dependency Injection. It is great for helping you test and not coupling objects. With that in mind, it is likely you would not actually have a collection of concrete DayViewModel objects but rather IDay. Then let your factory do the work of giving you the right object.

          Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.

          1 Reply Last reply
          0
          • M Member 1033907

            This one will be easy, I guess. Suppose I have a model class, for example Day, with its properties. Then I have DayViewModel, which wraps the Day for viewing, presents some other properties which are not present in the model class (like TimeOfSunset which can be computed, whatever, it's an example). Then I have Week class, which is a collection of Day objects + additional properties. Then again, WeekViewModel which wraps Week for viewing. I am not doing this automatically - one VM class for each M class, I really need to show Days (in a list maybe), hence the DayViewModel, and I want to show and interact with Weeks, hence the WeekViewModel. Now to the question. The Week class must include some property like List<Day> Days; which will be populated when the Week is loaded from the data store. But WeekViewModel requires something more like ObservableCollection<DayViewModel>. Now this is awkward, I already have one collection and I need to create another with the same physical data, just to change Day to DayViewModel and List to ObservableCollection. I could live with that but it gets worse. Whenever the WeekViewModel's ObservableCollection gets changed, I must take care to change the Week's List accordingly so that when I save the model classes to the data store, I am sure to have the most recent version. What is the common way to deal with this simple scenario? I believe that one of the benefits of MVVM is the fact, that several ViewModels can work with one Model just like several Views can work with one ViewModel (correct me if I am wrong). Following this principle, I can't simply use ObservableCollection<DayViewModel> directly in the Week (model) class, because that would tie the Model with one particular ViewModel. So, is there a better way around this than the one I outlined? I'll be happy to hear your suggestions, H.

            S Offline
            S Offline
            SledgeHammer01
            wrote on last edited by
            #5

            This is where people go wrong with MVVM. Over thinking things. Over engineering things. Why do you need a Day AND a DayModel? A Day IS a DayModel. You should most certainly NOT have a DataProvider that returns a POCO object and then have your UI wrap it in a model type clas. Your DataProvider should return an object that implements INPC in some form. There is also no such rule that says you have to have 1:1 relationship between M and VM. A VM can most certainly use / expose 2 or 20 M's.

            L M 2 Replies Last reply
            0
            • S SledgeHammer01

              This is where people go wrong with MVVM. Over thinking things. Over engineering things. Why do you need a Day AND a DayModel? A Day IS a DayModel. You should most certainly NOT have a DataProvider that returns a POCO object and then have your UI wrap it in a model type clas. Your DataProvider should return an object that implements INPC in some form. There is also no such rule that says you have to have 1:1 relationship between M and VM. A VM can most certainly use / expose 2 or 20 M's.

              L Offline
              L Offline
              Lost User
              wrote on last edited by
              #6

              I agree with most of what you are saying other than the over engineering. The OP clearly stated it is just a simple example, so this comment could be misleading. There could be numerous reasons the the DayViewModel is needed ontop of the Day (model) object. 1.) Day/Week is provided by 3rd parties 2.) Day/Week is provided internally but is a locked object because it is provided to 3rd parties 3.) Data Layer is provided by 3rd party etc. etc. There are other reasons other than 3rd party invlovement. However, with that said using the right patterns and best practices one can easily create another layer and ensure the INPC object comes back to the VM objects. See my post explaining factories and DI. I am sure there are other ways to accomplish this. I just think that saying one is over engineering can lead to problems and confusion. The question is a very good one, and the OP just needs some guidance on other practices. Making a comment like that may stear the OP away from a practice that should be considered, thus causing the system being developed to become somewhat chaotic.

              Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.

              S 1 Reply Last reply
              0
              • L Lost User

                I agree with most of what you are saying other than the over engineering. The OP clearly stated it is just a simple example, so this comment could be misleading. There could be numerous reasons the the DayViewModel is needed ontop of the Day (model) object. 1.) Day/Week is provided by 3rd parties 2.) Day/Week is provided internally but is a locked object because it is provided to 3rd parties 3.) Data Layer is provided by 3rd party etc. etc. There are other reasons other than 3rd party invlovement. However, with that said using the right patterns and best practices one can easily create another layer and ensure the INPC object comes back to the VM objects. See my post explaining factories and DI. I am sure there are other ways to accomplish this. I just think that saying one is over engineering can lead to problems and confusion. The question is a very good one, and the OP just needs some guidance on other practices. Making a comment like that may stear the OP away from a practice that should be considered, thus causing the system being developed to become somewhat chaotic.

                Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.

                S Offline
                S Offline
                SledgeHammer01
                wrote on last edited by
                #7

                If the OP doesn't want a simplified answer, he shouldn't post a simplified question. Its not the forums job to read his mind. Based on what he/she posted, there was nothing about any such restrictions or limitations and I interpreted him/her to be a MVVM newbie who like the rest of us started off a project with the goal of having "perfect" code and seperating everything out "perfectly". It sounded like the OP simply didn't know where to draw the MVVM line in the sand as opposed to constantly down voting people who didn't precisely agree with him.

                L 1 Reply Last reply
                0
                • S SledgeHammer01

                  If the OP doesn't want a simplified answer, he shouldn't post a simplified question. Its not the forums job to read his mind. Based on what he/she posted, there was nothing about any such restrictions or limitations and I interpreted him/her to be a MVVM newbie who like the rest of us started off a project with the goal of having "perfect" code and seperating everything out "perfectly". It sounded like the OP simply didn't know where to draw the MVVM line in the sand as opposed to constantly down voting people who didn't precisely agree with him.

                  L Offline
                  L Offline
                  Lost User
                  wrote on last edited by
                  #8

                  Seems like that is why you downvoting my post? (er gave it a 3). No responce or anything. I did not down post you because you did not agree with me. I downvoted it because he actually did state "Example" and you said you are over engineering and gave no resolution other than make you your Day object a view model. Your asnwer was a bad answer IMO (but not horrible... I gave you a 2). If you feel mine was as well I encourage you to challenge it by responding to it why that is bad practice or there is a better option and lead the way. OT - I do not give votes to those that simply disagree with my percpective. I give votes to those that either could mislead the OP (1 or 2 result depends on reasoning of the answer) or I give a vote because it is a good answer (4 or 5 result depends on clarity and accuracy). I rarely ever give a 3 because to me, you miaswell not vote then.

                  Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.

                  S 1 Reply Last reply
                  0
                  • L Lost User

                    Seems like that is why you downvoting my post? (er gave it a 3). No responce or anything. I did not down post you because you did not agree with me. I downvoted it because he actually did state "Example" and you said you are over engineering and gave no resolution other than make you your Day object a view model. Your asnwer was a bad answer IMO (but not horrible... I gave you a 2). If you feel mine was as well I encourage you to challenge it by responding to it why that is bad practice or there is a better option and lead the way. OT - I do not give votes to those that simply disagree with my percpective. I give votes to those that either could mislead the OP (1 or 2 result depends on reasoning of the answer) or I give a vote because it is a good answer (4 or 5 result depends on clarity and accuracy). I rarely ever give a 3 because to me, you miaswell not vote then.

                    Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.

                    S Offline
                    S Offline
                    SledgeHammer01
                    wrote on last edited by
                    #9

                    Actually, my response was 100% correct given the information the poster gave. Whether he said it was an example or not is irrelevant. He did not indicate that code involved was not his or off limits. Had he responded to my response with that fact, I may have provided a different answer. For now, I will stand by my response that separating the data layer into a POCO and a M just for the sake of doing so (thinking it is a good separation of duty) is completely un-necessary and completely over-engineered and it would have completely solved his problem of converting between a Day and a DayModel. Just as I will stand by my other response (that you also down voted) that the use of partial classes is completely proper. If you hate partial classes, well, you better go and explain yourself to Bill Gates (er, Steve Balmer) because pretty much ALL his technologies use them. Winforms, WPF, WCF, ADO.NET, etc. EDIT: BTW, I gave your post a 3 (should have probably gone lower though) because it was an abuse of technology given the scenario. Use of factories and DI for such a simple problem? Really? Why not go even further and use a remote https server behind a firewall using 512 bit encryption and a separate validation server to ensure the object is valid? :laugh:

                    L 2 Replies Last reply
                    0
                    • S SledgeHammer01

                      Actually, my response was 100% correct given the information the poster gave. Whether he said it was an example or not is irrelevant. He did not indicate that code involved was not his or off limits. Had he responded to my response with that fact, I may have provided a different answer. For now, I will stand by my response that separating the data layer into a POCO and a M just for the sake of doing so (thinking it is a good separation of duty) is completely un-necessary and completely over-engineered and it would have completely solved his problem of converting between a Day and a DayModel. Just as I will stand by my other response (that you also down voted) that the use of partial classes is completely proper. If you hate partial classes, well, you better go and explain yourself to Bill Gates (er, Steve Balmer) because pretty much ALL his technologies use them. Winforms, WPF, WCF, ADO.NET, etc. EDIT: BTW, I gave your post a 3 (should have probably gone lower though) because it was an abuse of technology given the scenario. Use of factories and DI for such a simple problem? Really? Why not go even further and use a remote https server behind a firewall using 512 bit encryption and a separate validation server to ensure the object is valid? :laugh:

                      L Offline
                      L Offline
                      Lost User
                      wrote on last edited by
                      #10

                      SledgeHammer01 wrote:

                      Actually, my response was 100% correct given the information the poster gave.

                      Your respnoce was simply a "You shouldn't do that." Nothing more nothing less. No explanation other than the claim of over engineering.

                      SledgeHammer01 wrote:

                      For now, I will stand by my response that separating the data layer into a POCO and a M just for the sake of doing so (thinking it is a good separation of duty) is completely un-necessary and completely over-engineered and it would have completely solved his problem of converting between a Day and a DayModel.

                      So, how are you going to handle a 3rd party controlled model? Or an object that you control that is used elsewhere and has embedded objects of which are not INOC? You make the assumption that the developer controls all aspects. In reality most patterns (Including MVVM) are created because we can not control all components. For the few, hey great. Code how you want. For the rest of the world we follow the patterns for easy transition, upgrades, extensions, testing etc. etc. etc

                      SledgeHammer01 wrote:

                      EDIT: BTW, I gave your post a 3 (should have probably gone lower though) because it was an abuse of technology given the scenario. Use of factories and DI for such a simple problem? Really? Why not go even further and use a remote https server behind a firewall using 512 bit encryption and a separate validation server to ensure the object is valid?

                      I doubt you have actually implimented a large scale MVVM project. The poster asked what is the common way to deal with that scenerio (you may want to go back and look... cause again you did not answer his question. You said he is over engineering). The scenerio is a very specific scenerio that large scale MVVM systems run into. And that is why we have other patterns. DI is NOT an abuse of technology and is actually quite simple. If however you system becomes large it gets complicated to maintain the intialization of yoru injected objects. In that case, you would be even more screwed with out it anyways and you need to simply start using some IoC. So explain to me how DI is too complicated for "such a simple problem"? You stating it is an abuse of technology is like stating OOP should not be used in simple apps. If you don't understand that, then it is likely you really don't understand what DI is.

                      S 2 Replies Last reply
                      0
                      • S SledgeHammer01

                        This is where people go wrong with MVVM. Over thinking things. Over engineering things. Why do you need a Day AND a DayModel? A Day IS a DayModel. You should most certainly NOT have a DataProvider that returns a POCO object and then have your UI wrap it in a model type clas. Your DataProvider should return an object that implements INPC in some form. There is also no such rule that says you have to have 1:1 relationship between M and VM. A VM can most certainly use / expose 2 or 20 M's.

                        M Offline
                        M Offline
                        Member 1033907
                        wrote on last edited by
                        #11

                        Thank you guys for all replies. No need to argue, really. To clarify a few points: the project which inspired the question is certainly more complex than counting days in a week (it is actually sports related but I came with the example to spare myself the need to explain the particular sport). It is a non commercial activity of mine and I though that one of the benefits would be to get comfortable with the celebrated MVVM. That is why I overthink things, because in this rare case I can afford it, and I can hardly get a thorough understanding by underthinking. SledgeHammer's reaction was my reasoning exactly - why complicate things with unneccessary model objects when viewmodel alone does all I need with no further complications. But most design patterns have use for model classes, so I thought there must be a "proper" (whatever it means) way to desing the application with model and viewmodel separated. I'll look into factory classes, thanks for the suggestion. I never said there is 1:1 correspondence between model and viewmodel classes, on the contrary. I remember now what made me think about the design the way I described. In one article on MVVM (don't know which one, maybe I read too many) someone said that model classes should contain only data that need to be stored in the data store. In particular, data which can be computed should not be present in the model classes but rather in the viewmodel. Back to my example - if the Day class contains a DateTime information about the time some employee came to work and another DateTime info when the employee left, it is all you need to store. Then my view wants to show how many hours the employee spend working, which can be computed from the data but it is job (I believe/ed) of the DayViewModel to provide this information. That is why I thought I needed both Day and DayViewModel. I got the impression that model classes store data, viewmodel contains all logic and view deals with appearance. I don't seek perfect code for the sake of it but I can hardly appreciate the benefits of MVVM for large scale applications if I can't successfully use it (with a bit of overkill) even for a small application. I'll be happy to hear any other suggestions and advice, H.

                        S 1 Reply Last reply
                        0
                        • L Lost User

                          SledgeHammer01 wrote:

                          Actually, my response was 100% correct given the information the poster gave.

                          Your respnoce was simply a "You shouldn't do that." Nothing more nothing less. No explanation other than the claim of over engineering.

                          SledgeHammer01 wrote:

                          For now, I will stand by my response that separating the data layer into a POCO and a M just for the sake of doing so (thinking it is a good separation of duty) is completely un-necessary and completely over-engineered and it would have completely solved his problem of converting between a Day and a DayModel.

                          So, how are you going to handle a 3rd party controlled model? Or an object that you control that is used elsewhere and has embedded objects of which are not INOC? You make the assumption that the developer controls all aspects. In reality most patterns (Including MVVM) are created because we can not control all components. For the few, hey great. Code how you want. For the rest of the world we follow the patterns for easy transition, upgrades, extensions, testing etc. etc. etc

                          SledgeHammer01 wrote:

                          EDIT: BTW, I gave your post a 3 (should have probably gone lower though) because it was an abuse of technology given the scenario. Use of factories and DI for such a simple problem? Really? Why not go even further and use a remote https server behind a firewall using 512 bit encryption and a separate validation server to ensure the object is valid?

                          I doubt you have actually implimented a large scale MVVM project. The poster asked what is the common way to deal with that scenerio (you may want to go back and look... cause again you did not answer his question. You said he is over engineering). The scenerio is a very specific scenerio that large scale MVVM systems run into. And that is why we have other patterns. DI is NOT an abuse of technology and is actually quite simple. If however you system becomes large it gets complicated to maintain the intialization of yoru injected objects. In that case, you would be even more screwed with out it anyways and you need to simply start using some IoC. So explain to me how DI is too complicated for "such a simple problem"? You stating it is an abuse of technology is like stating OOP should not be used in simple apps. If you don't understand that, then it is likely you really don't understand what DI is.

                          S Offline
                          S Offline
                          SledgeHammer01
                          wrote on last edited by
                          #12

                          Collin Jasnoch wrote:

                          Your respnoce was simply a "You shouldn't do that." Nothing more nothing less. No explanation other than the claim of over engineering.

                          Actually, my response was that they should be the same object and not two different ones which would solve the OPs problem. Given the info the OP posted, this was the correct answer.

                          Collin Jasnoch wrote:

                          So, how are you going to handle a 3rd party controlled model? Or an object that you control that is used elsewhere and has embedded objects of which are not INOC?
                          You make the assumption that the developer controls all aspects. In reality most patterns (Including MVVM) are created because we can not control all components. For the few, hey great. Code how you want. For the rest of the world we follow the patterns for easy transition, upgrades, extensions, testing etc. etc. etc

                          Who asked about 3rd party components? Certainly not the OP. Quit making up imaginary scenarios to justify your answer. Until the OP says that he is using 3rd party components that are not designed for MVVM, your point is completely irrelevant to the OPs question. Where do you get off saying I don't follow design patterns? I certainly do. I don't spend a month implementing a design pattern when a 5 minute "shortcut" will work "for now". I certainly don't write all my code using "shortcuts" or I wouldn't even use MVVM.

                          Collin Jasnoch wrote:

                          I doubt you have actually implimented a large scale MVVM project. The poster asked what is the common way to deal with that scenerio (you may want to go back and look... cause again you did not answer his question. You said he is over engineering).

                          Where do you get off saying what I have implemented or not? I'm actually working on a large scale MVVM project right now and yes, I am using 100% proper MVVM with DI, messenger to communicate between views, etc. I use technologies where appropriate. Not to feed my ego like you obviously do.

                          Collin Jasnoch wrote:

                          You stating it is an abuse of technology is like stating OOP should not be used in simple apps. If you don't understand that, then it is likely you really don't understand what DI is.

                          Lol... you need help bro. Go see a therapist. I certainly know what DI is. In fact, I have personally implemented a DI conta

                          L 1 Reply Last reply
                          0
                          • M Member 1033907

                            Thank you guys for all replies. No need to argue, really. To clarify a few points: the project which inspired the question is certainly more complex than counting days in a week (it is actually sports related but I came with the example to spare myself the need to explain the particular sport). It is a non commercial activity of mine and I though that one of the benefits would be to get comfortable with the celebrated MVVM. That is why I overthink things, because in this rare case I can afford it, and I can hardly get a thorough understanding by underthinking. SledgeHammer's reaction was my reasoning exactly - why complicate things with unneccessary model objects when viewmodel alone does all I need with no further complications. But most design patterns have use for model classes, so I thought there must be a "proper" (whatever it means) way to desing the application with model and viewmodel separated. I'll look into factory classes, thanks for the suggestion. I never said there is 1:1 correspondence between model and viewmodel classes, on the contrary. I remember now what made me think about the design the way I described. In one article on MVVM (don't know which one, maybe I read too many) someone said that model classes should contain only data that need to be stored in the data store. In particular, data which can be computed should not be present in the model classes but rather in the viewmodel. Back to my example - if the Day class contains a DateTime information about the time some employee came to work and another DateTime info when the employee left, it is all you need to store. Then my view wants to show how many hours the employee spend working, which can be computed from the data but it is job (I believe/ed) of the DayViewModel to provide this information. That is why I thought I needed both Day and DayViewModel. I got the impression that model classes store data, viewmodel contains all logic and view deals with appearance. I don't seek perfect code for the sake of it but I can hardly appreciate the benefits of MVVM for large scale applications if I can't successfully use it (with a bit of overkill) even for a small application. I'll be happy to hear any other suggestions and advice, H.

                            S Offline
                            S Offline
                            SledgeHammer01
                            wrote on last edited by
                            #13

                            I never said you shouldn't use MVVM. On the contrary, I think its great even for small apps once you have a good MVVM framework established. I just said you shouldn't separate the data layer from the model. I'll even toss Colin a bone here and add "unless there is a very good reason to do so". It doesn't seem that you are using any 3rd party components and it seems like you are owning all the code, so there is no reason to do so. I also never said anything about combining the model and viewmodel. Those should definitely be separate. The model should implement INPC (or derive from a base class that does) and should handle dealing with the data. I.e. writing to the database, or XML, etc. The viewmodel should well, I hate to use the word "repackage" because that might give you the impression that you are supposed to repackage the data, which you aren't. Its just a "gateway" from the model to the view. It just presents the data in a way the view can use it. Often times, this is just exposing a collection as a property to get the data to the view. It really doesn't have to be all that complicated. With a few exceptions, most of the VMs I've seen in my life are very simple which is one of the joys of MVVM IMO. If the VM is doing a ton of work in manipulating the data, something is wrong somewhere. The VM also exposes commands that the View can use to manipulate the model, but its just a hook up. The real work of manipulating the models internals belong in the model.

                            M 1 Reply Last reply
                            0
                            • L Lost User

                              SledgeHammer01 wrote:

                              Actually, my response was 100% correct given the information the poster gave.

                              Your respnoce was simply a "You shouldn't do that." Nothing more nothing less. No explanation other than the claim of over engineering.

                              SledgeHammer01 wrote:

                              For now, I will stand by my response that separating the data layer into a POCO and a M just for the sake of doing so (thinking it is a good separation of duty) is completely un-necessary and completely over-engineered and it would have completely solved his problem of converting between a Day and a DayModel.

                              So, how are you going to handle a 3rd party controlled model? Or an object that you control that is used elsewhere and has embedded objects of which are not INOC? You make the assumption that the developer controls all aspects. In reality most patterns (Including MVVM) are created because we can not control all components. For the few, hey great. Code how you want. For the rest of the world we follow the patterns for easy transition, upgrades, extensions, testing etc. etc. etc

                              SledgeHammer01 wrote:

                              EDIT: BTW, I gave your post a 3 (should have probably gone lower though) because it was an abuse of technology given the scenario. Use of factories and DI for such a simple problem? Really? Why not go even further and use a remote https server behind a firewall using 512 bit encryption and a separate validation server to ensure the object is valid?

                              I doubt you have actually implimented a large scale MVVM project. The poster asked what is the common way to deal with that scenerio (you may want to go back and look... cause again you did not answer his question. You said he is over engineering). The scenerio is a very specific scenerio that large scale MVVM systems run into. And that is why we have other patterns. DI is NOT an abuse of technology and is actually quite simple. If however you system becomes large it gets complicated to maintain the intialization of yoru injected objects. In that case, you would be even more screwed with out it anyways and you need to simply start using some IoC. So explain to me how DI is too complicated for "such a simple problem"? You stating it is an abuse of technology is like stating OOP should not be used in simple apps. If you don't understand that, then it is likely you really don't understand what DI is.

                              S Offline
                              S Offline
                              SledgeHammer01
                              wrote on last edited by
                              #14

                              Collin Jasnoch wrote:

                              I did not vote on any of your 'Partial Class' posts. I will inform you I voted for you comment on IValueConvertor

                              SledgeHammer01 wrote:

                              In MVVM, IValueConverter and IMultiValueConverter
                              are very rarely used because the VM does that work.

                              That is because that statement is completely false.
                              Maybe in your applications you have programmed this way, but a small search on google will show you they deffinately have their place.

                              Do you not understand the difference between "rarely" and "never". You should actually read the latest response from the OP in which he clearly states that all your imaginary doom scenarios are not at play, so following your own "don't mislead the OP" rule, I have to down vote you.

                              L 1 Reply Last reply
                              0
                              • S SledgeHammer01

                                Collin Jasnoch wrote:

                                Your respnoce was simply a "You shouldn't do that." Nothing more nothing less. No explanation other than the claim of over engineering.

                                Actually, my response was that they should be the same object and not two different ones which would solve the OPs problem. Given the info the OP posted, this was the correct answer.

                                Collin Jasnoch wrote:

                                So, how are you going to handle a 3rd party controlled model? Or an object that you control that is used elsewhere and has embedded objects of which are not INOC?
                                You make the assumption that the developer controls all aspects. In reality most patterns (Including MVVM) are created because we can not control all components. For the few, hey great. Code how you want. For the rest of the world we follow the patterns for easy transition, upgrades, extensions, testing etc. etc. etc

                                Who asked about 3rd party components? Certainly not the OP. Quit making up imaginary scenarios to justify your answer. Until the OP says that he is using 3rd party components that are not designed for MVVM, your point is completely irrelevant to the OPs question. Where do you get off saying I don't follow design patterns? I certainly do. I don't spend a month implementing a design pattern when a 5 minute "shortcut" will work "for now". I certainly don't write all my code using "shortcuts" or I wouldn't even use MVVM.

                                Collin Jasnoch wrote:

                                I doubt you have actually implimented a large scale MVVM project. The poster asked what is the common way to deal with that scenerio (you may want to go back and look... cause again you did not answer his question. You said he is over engineering).

                                Where do you get off saying what I have implemented or not? I'm actually working on a large scale MVVM project right now and yes, I am using 100% proper MVVM with DI, messenger to communicate between views, etc. I use technologies where appropriate. Not to feed my ego like you obviously do.

                                Collin Jasnoch wrote:

                                You stating it is an abuse of technology is like stating OOP should not be used in simple apps. If you don't understand that, then it is likely you really don't understand what DI is.

                                Lol... you need help bro. Go see a therapist. I certainly know what DI is. In fact, I have personally implemented a DI conta

                                L Offline
                                L Offline
                                Lost User
                                wrote on last edited by
                                #15

                                SledgeHammer01 wrote:

                                Actually, my response was that they should be the same object and not two different ones which would solve the OPs problem. Given the info the OP posted, this was the correct answer.

                                Exact Responce:

                                SledgeHammer01 wrote:

                                This is where people go wrong with MVVM. Over thinking things. Over engineering things. Why do you need a Day AND a DayModel? A Day IS a DayModel. You should most certainly NOT have a DataProvider that returns a POCO object and then have your UI wrap it in a model type clas. Your DataProvider should return an object that implements INPC in some form.

                                Sounds like you first told him he over engineered his "EXAMPLE". Then you went on to say he does not need a Day and DayModel (don't think the OP even mentioned DayModel... I will take this as a typo and assume ViewModel). Then you went on to talk about the data provider should return an INOC. Not clear. Not concise. Not a good answer. Keep griping. It will certainly get me to change my mind

                                SledgeHammer01 wrote:

                                Who asked about 3rd party components? Certainly not the OP. Quit making up imaginary scenarios to justify your answer. Until the OP says that he is using 3rd party components that are not designed for MVVM, your point is completely irrelevant to the OPs question.
                                 
                                Where do you get off saying I don't follow design patterns? I certainly do. I don't spend a month implementing a design pattern when a 5 minute "shortcut" will work "for now". I certainly don't write all my code using "shortcuts" or I wouldn't even use MVVM.

                                The OP asked how this is handled. I explained. Asking why (which you have done under your gripe about being down voted for a poor answer) will get you the why... being the examples I gave.

                                SledgeHammer01 wrote:

                                Where do you get off saying what I have implemented or not?

                                If the shoe fits. You have stated the user should not use DI and should impliment INOC on the returning data access blindly ignoring that in the real world most objects being returned from the data layer are used by multiple consumers. Yes in a simple case who cares. Again, the user asked about what others do. I provided and you told him he over engineered an example code base.

                                SledgeHammer

                                1 Reply Last reply
                                0
                                • S SledgeHammer01

                                  Collin Jasnoch wrote:

                                  I did not vote on any of your 'Partial Class' posts. I will inform you I voted for you comment on IValueConvertor

                                  SledgeHammer01 wrote:

                                  In MVVM, IValueConverter and IMultiValueConverter
                                  are very rarely used because the VM does that work.

                                  That is because that statement is completely false.
                                  Maybe in your applications you have programmed this way, but a small search on google will show you they deffinately have their place.

                                  Do you not understand the difference between "rarely" and "never". You should actually read the latest response from the OP in which he clearly states that all your imaginary doom scenarios are not at play, so following your own "don't mislead the OP" rule, I have to down vote you.

                                  L Offline
                                  L Offline
                                  Lost User
                                  wrote on last edited by
                                  #16

                                  Yep, and to tell someone that something is 'Rarely' used when it certainly has its place is false. In other words inaccurate and deserves a low vote. You can find literally thousands of blogs talking about usage of IValueConverters. I will admit that IMultiValueConverters have had some debate, but I think it is more likely due to their mis-use as they are by definition more complicated. IValueConverters on the other hand are simple and keep with SOC. Embedding the logic in the VM is the reverse and is bad practice. [EDIT] Read his posts, and confused by your 'doom' scenerios comment. What doom scenerios. Again, it seems one should use best practices no matter the scale. Yes if it doesn't make sence you don't apply, because that is not best practice. For example, your exaggeration about encryption. If one does not care about encryption they obviously would not make a layer for it. However, washing away DI as you did saying it is over engineering is completely misleading. DI is quite simply and so are factories. It clearly solves the problem. I voted based on your content of your answer. I know and do actually agree with your point (people over engineer). And if you worded it better I would have gave you a 5. However, claiming my answer was over engineered is also poor taste. DI in its simplest wording is this: interface Saying that is overengineering is a ridiculous notion. Moreover, I introduced to the OP how these problems are handled. That was his question. Your answer was it is not a problem because his system is small. Again poor taste as he said it was an example. The poster has come back and said your point is what he was looking for, hopefully you didn't mislead him too much. As I said, I do agree with your point but you worded it poorly to mislead.

                                  Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.

                                  1 Reply Last reply
                                  0
                                  • S SledgeHammer01

                                    I never said you shouldn't use MVVM. On the contrary, I think its great even for small apps once you have a good MVVM framework established. I just said you shouldn't separate the data layer from the model. I'll even toss Colin a bone here and add "unless there is a very good reason to do so". It doesn't seem that you are using any 3rd party components and it seems like you are owning all the code, so there is no reason to do so. I also never said anything about combining the model and viewmodel. Those should definitely be separate. The model should implement INPC (or derive from a base class that does) and should handle dealing with the data. I.e. writing to the database, or XML, etc. The viewmodel should well, I hate to use the word "repackage" because that might give you the impression that you are supposed to repackage the data, which you aren't. Its just a "gateway" from the model to the view. It just presents the data in a way the view can use it. Often times, this is just exposing a collection as a property to get the data to the view. It really doesn't have to be all that complicated. With a few exceptions, most of the VMs I've seen in my life are very simple which is one of the joys of MVVM IMO. If the VM is doing a ton of work in manipulating the data, something is wrong somewhere. The VM also exposes commands that the View can use to manipulate the model, but its just a hook up. The real work of manipulating the models internals belong in the model.

                                    M Offline
                                    M Offline
                                    Member 1033907
                                    wrote on last edited by
                                    #17

                                    I am starting to get it now. As I explained, I lived under the impression that model classes should only store data and not contain any means to manipulate them (this belongs to viewmodel). I learned this in some MVVM article, possibly not very good one because you say the direct opposite. Still it is good to know there are ways to deal with data sources I do not have under my control, so I appreciate Colin's input. But suppose the UI allows for direct manipulation with the individual Day objects (which are low in the whatever-Week-Day hierarchy). I could implement this by exposing a Manipulate (or something) command in the Day class, but rather in the DayViewModel class, since command handling is the viewmodel's job, right? If so, I am back to square one since I need the Day model class which manipulates the data and the DayViewModel which exposes the manipulation commands. If this is correct that the question still stands, how can the Week model class contain a collection of Day objects if it actually needs DayViewModel objects and thus would have to be tied with one particular viewmodel? If you say to expose the commands directly in the Day class, then I really see no point of VM layer since it would do nothing of any value.

                                    L 1 Reply Last reply
                                    0
                                    • M Member 1033907

                                      I am starting to get it now. As I explained, I lived under the impression that model classes should only store data and not contain any means to manipulate them (this belongs to viewmodel). I learned this in some MVVM article, possibly not very good one because you say the direct opposite. Still it is good to know there are ways to deal with data sources I do not have under my control, so I appreciate Colin's input. But suppose the UI allows for direct manipulation with the individual Day objects (which are low in the whatever-Week-Day hierarchy). I could implement this by exposing a Manipulate (or something) command in the Day class, but rather in the DayViewModel class, since command handling is the viewmodel's job, right? If so, I am back to square one since I need the Day model class which manipulates the data and the DayViewModel which exposes the manipulation commands. If this is correct that the question still stands, how can the Week model class contain a collection of Day objects if it actually needs DayViewModel objects and thus would have to be tied with one particular viewmodel? If you say to expose the commands directly in the Day class, then I really see no point of VM layer since it would do nothing of any value.

                                      L Offline
                                      L Offline
                                      Lost User
                                      wrote on last edited by
                                      #18

                                      Member 1033907 wrote:

                                      I lived under the impression that model classes should only store data and not contain any means to manipulate them (this belongs to viewmodel). I learned this in some MVVM article, possibly not very good one because you say the direct opposite.

                                      Your model class should not have any logic. It some cases it doesn't exist in code. For example I have a DataBase with a DataTable of Customers. Through my services I can get the data but my client code still needs to build the object. This object can use the INotifyPropertyChange interface, which would then end up my View Model. The model 'Customers' exists inside my data base.

                                      Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.

                                      1 Reply Last reply
                                      0
                                      • S SledgeHammer01

                                        Actually, my response was 100% correct given the information the poster gave. Whether he said it was an example or not is irrelevant. He did not indicate that code involved was not his or off limits. Had he responded to my response with that fact, I may have provided a different answer. For now, I will stand by my response that separating the data layer into a POCO and a M just for the sake of doing so (thinking it is a good separation of duty) is completely un-necessary and completely over-engineered and it would have completely solved his problem of converting between a Day and a DayModel. Just as I will stand by my other response (that you also down voted) that the use of partial classes is completely proper. If you hate partial classes, well, you better go and explain yourself to Bill Gates (er, Steve Balmer) because pretty much ALL his technologies use them. Winforms, WPF, WCF, ADO.NET, etc. EDIT: BTW, I gave your post a 3 (should have probably gone lower though) because it was an abuse of technology given the scenario. Use of factories and DI for such a simple problem? Really? Why not go even further and use a remote https server behind a firewall using 512 bit encryption and a separate validation server to ensure the object is valid? :laugh:

                                        L Offline
                                        L Offline
                                        Lost User
                                        wrote on last edited by
                                        #19

                                        Haha. Didn't like my responce so you 1 voted it? Good for you! Not gonna change the way I vote though. You can go ahead and one vote me all you want. It will prove to everyone you are just a troll.

                                        Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.

                                        1 Reply Last reply
                                        0
                                        Reply
                                        • Reply as topic
                                        Log in to reply
                                        • Oldest to Newest
                                        • Newest to Oldest
                                        • Most Votes


                                        • Login

                                        • Don't have an account? Register

                                        • Login or register to search.
                                        • First post
                                          Last post
                                        0
                                        • Categories
                                        • Recent
                                        • Tags
                                        • Popular
                                        • World
                                        • Users
                                        • Groups