J
J
Jaguar_sea2015-07-14 03:52:46
WPF
Jaguar_sea, 2015-07-14 03:52:46

Should UserControl be used in WPF MVVM?

Good day! I'm trying to figure out the MVVM pattern. In my tutorial application, which visualizes some data from the database and helps to perform CRUD operations, I'm trying to understand windowing in particular. It is clear that in order to perform CRU operations, it is necessary to show the user a modal window. But what's the easiest way to do it? Create a separate full-fledged window with textboxes and buttons for each table, or still create one window in which there will be only buttons and, depending on the table being edited, this or that UserControl will be loaded? For the second approach, unfortunately, I could not find examples. Please help with a link to an article or a ready-made sample application. And if not difficult, tell us about the pros and cons of these two approaches.

Answer the question

In order to leave comments, you need to log in

3 answer(s)
L
Larry Underwood, 2015-07-14
@Jaguar_sea

Your approach is fundamentally wrong.
Let's go in order.
First read about DataContext in WPF, then about MVVM itself (more carefully than before).
According to the data structure: one table is one type of aggregation, respectively, another table is a different type of aggregation, I will explain for example:
there is a table products (Id, Product Code) and there is a table customers (Id, Name, Code of the ordered product), for the products table, you need to create a Product class

class Product : INotifyPropertyChanged
{
  public int Id {get;set;}
  public int Code {get;set;}
  // + реализация INPC
}

On INotifyPropertyChanged, google what it is.
Then create a Consumer class for the customers table
class Consumer
{
  public int Id {get;set;}
  public string Name {get;set;}
  public IEnumerable<Product> Orders {get;set;}
}

The data is selected from the database and for each table an instance of the class corresponding to it must be created.
Create a class with a context
class MyShopViewModel : INotifyPropertyChanged
{
 // Выбранный элемент, для которого будем отображать модальное окно
  public object SelectedItem {get;set;}
}

Somewhere in the code where the modal window opens, for example, in the ShowObjectEditor method, you do:
public void ShowObjectEditor()
{
  // создаем окно с редактором объекта БД
  var objectEditor = new ObjectEditorView();
  // Устанавливаем ему DataContext, Где myShopViewModel - Объект класса MyShopViewModel
  objectEditor.DataContext = myShopViewModel;
  // показываем окно
  objectEditor.Show();
}

В разметке ObjectEditorView
<Window>
  <ContentPresenter Content="{Binding SelectedItem}"/>
</Window>

But the ContentPresenter does not know how to show it, and here the answer to your question opens: for each data type, write a DataTemplate in the window resources, I have two types - products and customers, and the markup takes the form
<Window>
  <Window.Resources>
    <ResourceDictionary>
     <DataTemplate TargetType={x:Type Product}>
      // вот тут и описываем чекбоксы и прочую хрен.
     </DataTemplate>
     <DataTemplate TargetType={x:Type Consumer}>
      // вот тут и описываем чекбоксы и прочую хрен.
     </DataTemplate>
    <.ResourceDictionary>
  <.Window.Resources>
  <ContentPresenter Content="{Binding SelectedItem}"/>
</Window>

Now, for each type of data, its own markup will automatically be pulled up and it will be located in one window.
What is not clear - ask in the comments.

R
Roman, 2015-07-14
@yarosroman

What's the difference? Or a bunch of separate classes for separate windows, the same number of separate UserControl + one class for one common modal window. Plus, in the constructor of this window there will be clutter in the form of creating UserControls depending on the transmitted data or parameters, or a bunch of constructors, everything is simple when there are 5 windows, and when there are 20-30 of them, then it will be easy to get confused, and separate windows, with sane names (for example, ActionEntityNameWindow - AddCustomerWindow, EditProductWindow, etc., without confusing the types CustomerAddWindow and EditProductWindow), it will be easier to maintain in the future. If necessary, you can create a builder class, with separate methods for creating windows, entities, and the necessary parameters.

A
AxisPod, 2015-07-14
@AxisPod

Well, in general, if you want to complicate your life, do not use UserControl.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question