9

I am new in MVVM and I am developping an application. I have a form view with a lot of property. About 50. I can not seperate these into usercontrol because I would break the mvvm principles.

I can not seperate these into model, because these contains logic. PropertyChange, Error change and these would not be poco classes, and these are not the model.

Would it be nice If I kept 60 property in a same viewmodel?

Do I think it wrong? How would you organize these?

Lajos
  • 2,549
  • 6
  • 31
  • 38
  • 4
    Why cannot you make a `UserControl` without breaking MVVM? – Viv Jun 17 '13 at 09:01
  • 2
    A good question by Viv. You can make ViewModels for user controls in your major ViewModel. Also you can use some sort of "Controller" layer for logic and keep ViewModel clean only with PropertyChanged implementation. The wisest way would be: create base viewmodel and derive from it. – VidasV Jun 17 '13 at 09:03
  • I knew I can not use UserController because of http://stackoverflow.com/questions/17048066/mvvm-light-test-viewmodel-with-view-and-create-staticresource-locator – Lajos Jun 17 '13 at 09:08
  • 2
    i would say: if you need to show 60 things in your view - then you have to keep the 60 properties in your viewmodel. but of course if you can split your view in usercontrols you can split your viewmodel too – blindmeis Jun 17 '13 at 09:13
  • It sounds good, and for example, I have a formview and a formviewmodel for it, could I write a addressviewmodel as a part of it? – Lajos Jun 17 '13 at 09:45

2 Answers2

2

I can not seperate these into usercontrol because I would break the mvvm principles.

I'm not sure what you mean by this. Essentially you'll want to use view composition and break down the view model and views into constiuent parts.

A view is a WPF UserControl (or Window), so if you're using MVVM then you're using UserControl's, it's just conceptually they are considered as views in the pattern.

I would also recommend that you use an MVVM framework if you're using the MVVM pattern, and something like Caliburn.Micro makes view composition incredibly easy.

I would also not recommend using dependency properties for view models, use INotifyPropertyChanged instead.

Most MVVM frameworks provide a base view model type which includes a lambda based method to invoke the PropertyChanged event, thus aiding refactoring.

Community
  • 1
  • 1
devdigital
  • 34,151
  • 9
  • 98
  • 120
  • I am new, but I read I can use usercontrol just with dependency properties, because all of the property should be in the view model and the usercontrol will display it by the dependency property. So if I used the usercontrol, the dep properties still stay in the view model. just there will be much more lines – Lajos Jun 17 '13 at 09:53
  • Your views will be UserControls that are declaritive XAML and will instantiate controls such as a TextBlock which will have dependency properties such as its Text property. The target of the binding needs to be a dependency property, but not the source. Therefore, your view model will implement INPC and the binding will still work as the TextBlock target property is a dependency property. – devdigital Jun 17 '13 at 09:56
  • ok, but in this case the properties in the master viewmodel will not be separated. can I create a viewmodel without view, and use it in the master viewmodel? – Lajos Jun 17 '13 at 09:59
  • Why can't they be separated? – devdigital Jun 17 '13 at 10:13
1

Please don't use PropertyChanged for 60 Properties. Use DependencyProperty. For terms of usabilty use the propdp Shortcut from Visual Studio and press Tab twice.

Please refer to this link: http://www.codeproject.com/Articles/62158/DependencyProperties-or-INotifyPropertyChanged

Johannes Wanzek
  • 2,825
  • 2
  • 29
  • 47
  • 3
    Well since the author of the articel pointed out some points, when it's recommended to implement `INotifyPropertyChanged` (e.g. testing), you shouldn't recomment using `DependencyProperty` without giving a hint, that there are some limitations. – DHN Jun 17 '13 at 09:40
  • Well since I posted the link to this article, the author of this question could read carefully through it :) But of course you are right, it would have been better to let him consider rather than just recommend using `DependencyProperty` – Johannes Wanzek Jun 17 '13 at 09:44
  • I'm sorry, I don't agree. *Please don't use PropertyChanged for 60 Properties. Use DependencyProperty.[...]* implies that there are no disadvantages. I know me and I know other developers...we hate wall of texts, so he might miss the disadvantages. – DHN Jun 17 '13 at 09:50
  • According to his question there is nothing wrong recommending `DependencyProperties`. For every other considerations the article can be read. – Johannes Wanzek Jun 17 '13 at 09:58
  • See this article for counter-argument: http://kent-boogaart.com/blog/view-models-pocos-versus-dependencyobjects/ : Conclusion: "I think the advantages of POCO view models [i.e. INotifiyPropertyChanged] over DependencyObject view models are clear and convincing. – Edward Nov 13 '15 at 11:16