Laden...

Wie kann ich bei ausgelagerten Properties den Datacontext richtig setzen?

Erstellt von TheLion092 vor 4 Jahren Letzter Beitrag vor 4 Jahren 1.063 Views
T
TheLion092 Themenstarter:in
17 Beiträge seit 2018
vor 4 Jahren
Wie kann ich bei ausgelagerten Properties den Datacontext richtig setzen?

Hallo,

mit der Zeit sammeln sich im ViewModel ja doch eine ganze Menge an Properties an. Diese würde ich der Übersicht halber gerne in eine eigene Klasse auslagern. Wie bekomme ich das dann mit dem DataContext hin. Der DataContext wurde bei mir im MainWindow.xaml.cs bereits zum ViewModel festgelegt, weil sich im ViewModel eine ObservableCollection befindet, die im View mit einem DataGrid verbunden ist.

Also kurz gesagt: Wie bekomme ich einen zweiten, zusätzlichen DataContext zu der ausgelagerten Properties-Klasse hin ?

Macht es überhaupt Sinn, die Properties auszulagern oder ist das unüblich ?

Liebe Grüße

16.807 Beiträge seit 2008
vor 4 Jahren

Macht es überhaupt Sinn, die Properties auszulagern oder ist das unüblich ?

Pauschal kann man es nicht sagen; aber wenn Du das "Bedürfnis" hast etwas auszulagern, dann ist das prinzipiell zumindest ein erster Hinweis, dass im Sinne von OOP die gesamte Klasse suboptimal aufgebaut ist.

5.657 Beiträge seit 2006
vor 4 Jahren

Meinst du so:


public class MainViewModel
{
  public SubViewModel1 Property1 { get; set; }
  public SubViewModel2 Property2 { get; set; }
}

<Control1 Content="{Binding Property1.SubPropertyA}" />
<Control2 Content="{Binding Property2.SubPropertyB}" />

Weeks of programming can save you hours of planning

T
TheLion092 Themenstarter:in
17 Beiträge seit 2018
vor 4 Jahren

Aaaaalsoo..

Ich habe folgendes in der MainWindow.xaml.cs stehen:


using NTFStool.ViewModels;
using System.Windows;

namespace NTFStool.Views
{
    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
            DataContext = new MainViewModel();
        }
    }
}

Das ist ein Ausschnitt aus dem MainViewModel:


using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.ComponentModel;
using System.Linq;
using System.Runtime.CompilerServices;
using System.Text;
using System.Threading.Tasks;
using System.Windows;
using System.Windows.Input;
using NTFStool.Models;
using NTFStool.AppLogic;
using NTFStool.Helpers;

namespace NTFStool.ViewModels
{
    public class MainViewModel : PropertyChangedEvent
    {

        //=> Liste der User
        private ObservableCollection<User> userlist = new ObservableCollection<User>();
        public ObservableCollection<User> Userlist
        {
            get { return userlist; }
            set { userlist = value; NotifyPropertyChanged(); }
        }

        //=> "Vorname" sichtbar
        private bool vornameEnabled = true; // Default: Sichtbar
        public bool VornameEnabled
        {
            get { return vornameEnabled; }
            set { vornameEnabled = value; NotifyPropertyChanged(); }
        }

        //=> "Nachname" sichtbar
        private bool nachnameEnabled = true; // Default: Sichtbar
        public bool NachnameEnabled
        {
            get { return nachnameEnabled; }
            set { nachnameEnabled = value; NotifyPropertyChanged(); }
        }

        .
        .
        .

    }
}

Im View ist das DataGrid, welches eine Datenbindung zur ObservableCollection hat.
Die Spalten des DataGrid sowie einige DockPanel-MenuItem's haben eine Datenbindung zu z.B. "Vorname sichtbar" oder "Nachname sichtbar".

Das funktioniert auch wunderbar. Wenn ich die Properties "Vorname sichtbar" oder "Nachname sichtbar" usw. nicht im ViewModel sehen will, sondern in eine eigene Klasse verschiebe, funktioniert die Datenbindung zwischen dem ControlItem im View und der Property im ViewModel nicht mehr:


<DataGrid  x:Name="datagrid" HeadersVisibility="Column" IsReadOnly="True" AutoGenerateColumns="False" ItemsSource="{Binding Userlist, UpdateSourceTrigger=PropertyChanged, Mode=OneWay}" Focusable="False">
...

<MenuItem Name="Ansicht_Vorname" Header="Vorname" IsCheckable="True" IsChecked="{Binding VornameEnabled}"/>

Ich habe derzeit auch noch eine zweite kleine Frage:
Ich habe einiges an Code, der im ViewModel stand in eine "Logic"-Klasse ausgelagert, auf die ich aus dem ViewModel zugreife. Mein Gedanke war einfach, das ViewModel etwas aufgeräumter zu bekommen. Manchmal weiß ich aber gar nicht, ob das überhaupt Sinn macht.
Was gehört denn alles an "Code-behind" ins ViewModel (Abgesehen von einer Klasse User natürlich, weil das gehört ja ins Model)? Ist es normal, dass das ViewModel ziemlich voll wird ?

Liebe Grüße

W
955 Beiträge seit 2010
vor 4 Jahren

MrSparkle wollte andeuten dass man eine View in mehrere Views auftrennen kann, also eine MainView die sich in verschiedene Views teilt: ListView, DetailView usw. Dasselbe dann mit ViewModels. Vllt passt das ja zu deinem Layout.

5.657 Beiträge seit 2006
vor 4 Jahren

@witte
Nein, mit der View hat das nichts zu tun.

Man kann Unter-ViewModells verwenden, wenn es sich um Aufgaben oder Zustande handelt, die logisch gekapselt werden sollten. Man muß halt dann das Binding anpassen!

Und ja, die UI-Logik gehört ins ViewModel, und die Anwendungs-Logik ins Model, nicht in irgendwelche "Logic-Klassen". Hier gibt es alle Infos dazu, was ins ViewModell gehört: [Artikel] MVVM und DataBinding

Weeks of programming can save you hours of planning

W
955 Beiträge seit 2010
vor 4 Jahren

Ich wollte damit sagen dass er eine komplexe View in verschiedene aufteilen kann mit jeweils ein eigenen VM. Natürlich kann man auch die View zusammen lassen und einzelne Teile des VM in andere Klassen auslagern, "Unter-ViewModells" wie du sie nennst.