CODEWITHSUNDEEP
c#wpfmvvmuser-controls
Paul
Paul

Reputation: 948

Should I try to follow MVVM when creating a user control

I am recreating a small app in WPF and I am trying to use MVVM where it makes sense. I started out thinking I would use it 100% of the time, and so far I have, but I've come to the conclusion that strict MVVM (no code-behind whatsoever) is not necessarily a positive thing.

Now I am trying to make a user control that will bind to a list and create a regular button for every item in the list. (Essentially I'm recreating a list-box but with a different style.) I am making this user control specifically to avoid creating the buttons on the fly in the main window's code-behind, but I am thinking that since everything is essentially "view", and all logic will be done elsewhere, I can just add the buttons in the code behind without technically breaking MVVM. Is this line of thinking correct, deeply flawed or somewhere in between? Thanks for any help!

Upvotes: 2

Views: 561

Answers (3)

Michael Brown
Michael Brown

Reputation: 9153

When learning MVVM it's usually best to start on the conservative side. Blindly saying MVVM for everything is putting the cart before the horse. Instead do things like you're comfortable doing them. The purpose of a pattern is to remove friction from development. When you see friction from the way you are doing things that a pattern can solve, that is the time to use the pattern. Once you see the benefit of using MVVM you will have a feel for when to preemptively apply it and when you can delay that decision. Also, by that time you will be familiar enough with it that it actually becomes easier to use than the other route.

For your specific question, the solution has been answered, you don't need code behind or a view model because, WPF templates take care of it for you. I'd suggest learning more about the template system in WPF, it's quite powerful and leads to more elegant solutions.

Upvotes: 3

Thomas Levesque
Thomas Levesque

Reputation: 292425

strict MVVM (no code-behind whatsoever)

MVVM doesn't forbid the use of code-behind... sometimes code-behind is the right place to do something, as long as it's purely UI-related.

However in that case I don't see the benefit of creating those buttons in code-behind, when you can easily make an ItemsControl with an ItemTemplate that will display buttons for each item in your collection.

<ItemsControl ItemsSource="{Binding YourCollection}">
    <ItemsControl.ItemTemplate>
        <DataTemplate>
            <Button Content="{Binding Text}" Command="{Binding DoSomethingCommand}" />
        </DataTemplate>
    </ItemsControl.ItemTemplate>
</ItemsControl>

Upvotes: 6

Tigran
Tigran

Reputation: 62246

The sentence "I am thinking that since everything is essentially "view", and all logic will be done elsewhere, I can just add the buttons in the code behind without technically breaking MVVM", is kind of self contravresal, by me. Cause assuming that button is UI, and pure UI is an XAML and code instead a kind of model and modelview stuff, you move UI to codebehind. I, peronally, would think to make UI customization in XAML, as much as it possible. Use standart ListView/ListBox control and do customization on that. This is kind of more tricky then just adding buttons in chain, but definitely more stable, as a lot of stuff is already thought in ready controls and the only think you need is to customize appearance of items, which where amazing power of WPF comes.

In short: by me, use standart controls and customize appearance of items inside XAML.

Regards.

Upvotes: 2

Related Questions