Shoud view layer know about model classes (entities)?

Question

I have Pack entity which is displayed on Shelf user control:

namespace Storage.Model
{
    class Pack
    {
        public string Name { get; set; }
    }
}

<UserControl x:Class="Storage.View.Shelf" ... >
    <Grid>
        <Grid.RowDefinitions>
            <RowDefinition Height="20" />
            <RowDefinition Height="50" />
            <RowDefinition Height="*" />
        </Grid.RowDefinitions>

        <TextBlock Grid.Row="0" Text="{Binding Path=Name}"/>
        <TextBlock Grid.Row="1" Text="{Binding Path=Capability}"/>
        <ItemsControl Grid.Row="2" ItemsSource="{Binding Path=Packs}">
            <ItemsControl.ItemTemplate>
                <DataTemplate>
                    <Border>
                        <TextBlock Text="{Binding Name}" /> // It's okey ???
                    </Border>
                </DataTemplate>
            </ItemsControl.ItemTemplate>
        </ItemsControl>

    </Grid>
</UserControl>

// DataContext for Shelf 
namespace Storage.ViewModel
{
    public class ShelfViewModel
    {
        public string Name { get; set; }
        public string Capability { get; set; }
        public ObservableCollection<Pack> Packs { get; set; }
    }
}

With MVVM model it's okay that in DataTemplate I have binding {Binding Name}, because if so: IT'S NOT TRUE THAT VIEW SHOULDN'T KNOW ABOUT MODEL CLASS.

You DON'T HAVE TO YELL us. That's not a model, though, it's a ViewModel — Camilo Terevinto, Jan 07 '18 at 20:16
@CamiloTerevinto My sincere apology about that :D But it's result of frustration: if you type for MVVM pattern in google image neither image show arrow between model and view. — Sonny D, Jan 07 '18 at 20:22
@CamiloTerevinto `Pack` is part of `Storage.Model` and `ObservableCollection` contains `Pack` class so it's part of model(domain). — Sonny D, Jan 07 '18 at 20:23
Who told you that the view shouldn't know the model? Why do you think that's wrong? The model is part of (or sometimes even derived from) the model. So obviously the view knows it. — Clemens, Jan 07 '18 at 20:49
@Clemens I start learning MVVM. All tutorials I follow say that we separate View form Model. Changes in one shouldn't cause change in second. But's it's not true, if I decide to refactor naming convention in model I need update my `DataTemplate`. — Sonny D, Jan 07 '18 at 21:05
You're probably reading the wrong tutorials. Be aware that there is a lot of nonsense on the internet about MVVM. — Clemens, Jan 07 '18 at 21:12
@CamiloTerevinto Introduction `PackViewModel` class will solve the issue, but create another one. How to populate newly `PackViewModel` class with reference to proper `Pack` class? — Sonny D, Jan 07 '18 at 21:13
@Clemens I will be grateful for link to good MVVM tutorials. — Sonny D, Jan 07 '18 at 21:16

score 1 · Accepted Answer · answered Jan 08 '18 at 11:38

It depends on how you define a "model". A model may for example be a reference to a service or business layer. Or it might be an entity object.

It is perfectly fine for the view to bind directly to a property of an entity object that that is exposed through a public property of a view model provided that you actually have access to the entity type and that don't need to modify the definition of it in any way.

Let's for example say that Pack is a domain type that contains proprietary business logic and is used in several different places accross your business. You might not want to expose such as class to a client application at all. You would typically have some kind of business layer and then a service layer on top of this, that connects to the business layer and returns simple data transfer objects (DTOs) rather than the actual business entities that contains logic.

You can easily bind to such a DTO object directly as long as you don't need it to do something special like for example providing change notifications to the UI. The you will need to write a wrapper (view model) class that exposes the underlying data but also adds the change notification functionality.

So if Pack is a simple public type that contains everything you need, then you could use it directly. This doesn't break any rule. It if's something else, then use a client specific, or view-aware, wrapper class.

Thanks for response, I mark it as right answer. Your reply satisfies all my concerns. The conclusion is that: depending on the design we want or don't want expose some info to `View`. All absolute dogma isn't true :D — Sonny D, Jan 08 '18 at 12:39

score 0 · Answer 2 · answered Jan 07 '18 at 21:53

0

It's programming, so the answer is always "it depends".

If your model has all data in the format that the View needs and the model is immutable, then why not be pragmatic and directly bind the Model to the View?

But as soon as you need a command, write-access to the model properties, data convertion inbetween model and view or if the model properties can change (and you don't want to implement INotifyPropertyChanged on your model) then you shoud wrap a ViewModel arround your model to adress this issues.

answered Jan 07 '18 at 21:53

Jonas Benz

503
3
12

I totally agree with you that in programming all depends on sth. If I follow your suggestion and introduce Pack ViewModel I end up with:https://stackoverflow.com/questions/48141919/viewmodel-contains-collection-of-another-viewmodel. – Sonny D Jan 07 '18 at 22:00
@SonnyD Both solutions are valid. If your view is the only one that updates the "Name" propery of the referenced Pack and you don't want to implement some validation or something else inbetween, then it is ok to directly bind to your model from the view – Jonas Benz Jan 07 '18 at 22:12

Shoud view layer know about model classes (entities)?

2 Answers2

Linked