Was Du mit den Predicates machen willst, geht langfristig in die Hose.
Es gibt/gab zwar ein Framework, das eine LambdaExpression als String de/serialisiert, das könntest Du dann speichern, aber wie gesagt: Das geht in die Hose ^^

Du meinst https://github.com/esskar/Serialize.Linq oder?

PS: Wie gesagt es geht nicht darum wie, die Konfig abgespeichert wird (ob DB oder in Azure App Configuration spielt ja für die eigentliche Anforderung keine Rolle)

Es gibt Anwendungen wo eine variable Struktur in json serialisiert wird und dann in einer Datenbank gespeichert wird.

Grüße Bernd

Die Struktur des Typen bleibt immer gleich. Ich bräuchte aber so etwas wie eine Funktion die true oder false zurückgibt (die als Parameter den Typ Car übergeben bekommt). Für jede Konfiguration schaut dann die Funktion anderst aus. Als z.B. so etwas:

//konfig liste vom backend
konfig=new List<Konfig> ()
{
      new Konfig() { new Predicate<Car>(s => s.Doors == 1)},
      new Konfig() { new Predicate<Car>(s => s.Typ == "2")},
      new Konfig() { new Predicate<Car>(s =>
            {
                Regex regex = new Regex(".");
                return regex.IsMatch(s.Typ);
            });
      ....
}
//evaluierung welche cars aufgrund der konfig hinzugefügt werden dürfen

            List<Car> cars = GetCars();
            foreach (var car in cars)
            {
                foreach (var konfig in konfig)
                {
                    if(konfig.Predicate.Invoke(car)) //predicate gibt true oder false zurück
                    {
                        yield return car;
                    }
                }
            }

Ich schau mir jetzt noch https://github.com/microsoft/ClearScript an, schaut auch intressant aus.

Hi,

ich möchte eine Konfiguration möglichst dynamisch und flexibel halten (Diese soll einen konkreten Typ konfigurierbar machen - hier Car). Dazu wird die Konfiguration in einer DB gehalten und dann auf dem Client heruntergeladen und später ausgeführt. Derzeit ist dies alles statisch und soll nun eben flexibler werden. Später soll man die Konfiguration über ein Webinterface bearbeiten können.

Ich hätte zuerst folgenden Lösungsansatz verfolgt: In die Konfig ein Predicate<Car> geben und den Predicate in der DB Serialisieren.

new Predicate<Car>

Leider ist das Serialisieren mit dem BinarySerializer von delegates deprecated. Während der Recherche ist mir noch DLR untergekommen. Gibt es vlt. noch eine weitere Technik die mir hier weiterhelfen könnte? Hätten ihr Tipps für mein Vorhaben? Danke im Voraus.

    class Car
    {
        public int Doors { get; set; }
        public string Typ { get; set; }

        ...
    }

Setze einen Haltepunkt nach dem Laden der Oberfläche und gib den DataContext vom ComboBox Control aus. Hast du im Output irgendwelche Binding Errors?

Wahrscheinlich passt ein Binding nicht.

Das könnte vlt auch helfen https://get-the-solution.net/blog/ItemsSource%20zu%20UserControl%20hinzuf%C3%BCgen

openshift.com - da gibts auch eine free version (natürlich mit einschränkungen)

https://docs.openshift.com/container-platform/3.3/using_images/s2i_images/dot_net_core.html

IoC - Inversion of Control bedeudet, dass du die Steuerung deines Programmablauf abgibst.

Äh, nein, das bedeutet es nicht. Es bedeutet, dass die konsumierende Klasse bestimmt, wie Teilaspekte des Programmablaufs, der in der/den ausführenden Klasse(n) definiert ist, implementiert sind. Die ausführenden Klassen geben die Verantwortung für die Implementierung ab. Dadurch wird der Konsument anstelle der ausführenden Klasse zum steuernden Teil - inversion of control, literally.

Äh... nein und nochmal nein. Es heißt "Statt dass die Anwendung den Kontrollfluss steuert und lediglich Standardfunktionen benutzt, wird die Steuerung der Ausführung bestimmter Unterprogramme an das Framework abgegeben."

IoC - Inversion of Control bedeudet, dass du die Steuerung deines Programmablauf abgibst. Du schreibst deinen Programmcode nur noch in die Schablone. Das Framework ruft, dann deinen Programcode auf. Daher auch als Hollywood Prinzip bekannt. Don't call us, we call u.

Dependecy Injection - Bei der Dependecy Injection gibt man die Objekterzeugung ab. Heutige DI Frameworks können Abhänigkeiten bei der Objekterzeugung erkennen und lösen diese in richtiger Reihenfolge und Abhänigkeit auf. Sollte z.B. die Implementierung IDependency eine Abhänigkeit auf Komponente xy haben, muss zuerst diese erzeugt werden. Erst danach kann IDependecy aufgelöst werden.

Die Begriffe gleichzusetzen ist etwas heikel.

Gab es nichts neues zum XAML Standard? Ich habe dazu nur eine Preview Doc Seite gefunden aber die ist aus 2017.

Danke für den Hinweis auf diesen tollen Eintrag. der hat mir sehr gefallen.
Leider ist das zu allgemein, dass es mein Problem löst, aber trotzdem interessant.
Ich habe das Problem, dass ich nicht weiß wie ich eine Row mit Mouse-Klick auswähle und dann per Button mein Löschkommando ausführe. Es ist dieses Auswählen von einem Datensatz das ich im ViewModel dem Löschen bereitstellen muss.

Wenn das DataGrid oder Control keine passende SelectedItem DependencyProperty (oder der gleichen) hat kannst du auf
*Behavior *Attached properties

zurückgreifen. Schau dir vlt. auch den Anhang vom Beitrag Verlinkungsproblem: System.Windows.Interactivity keine gültige Namespace-ID an.

Bei den Attached Properties geht man so vor, dass man im DependencyPropertyChangedCallBack, vom Control (bei dir das Datagrid) das passende Event registriert und dann z.B. einen Command ausführt.

Lies mal die Comments von dem Thread, dann verstehst du vlt. worauf ich hinaus wollte:
https://www.reddit.com/r/microsoft/comments/7o46xb/microsofts_beautiful_cortanapowered_thermostat_is/