Validierung einer Klasse

Talemantros · Verfasst: Mi 16.12.15 20:55

Hallo,
ich habe folgende Klasse mit der MEthode "IsValid" von euch damals erklärt bekommen.

C#-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:
85:
86:
87:
88:
89:
90:
91:
92:
93:
94:
95:
96:
97:
98:

    public class Article
    {
        public long Id { get; set; }
        public long ArticleId { get; set; }
        public long? Customer { get; set; }
        public string CustomerString { get; set; }
        public long? CustomerUnit{ get; set; }
        public string CustomerUnitString { get; set; }
        public long? CustomerTp { get; set; }
        public string CustomerTpString { get; set; }
        public long? CustomerCrap { get; set; }
        public string CustomerCrapString { get; set; }
        public string CrapColor { get; set; }
        public long? Container { get; set; }
        public string ContainerString { get; set; }
        public string ContainerNumberActuell { get; set; }
        public long? ContainerWithout { get; set; }
        public string ContainerWithoutString { get; set; }
        public string ContainerNumber { get; set; }
        public decimal CrapBrutto { get; set; }
        public decimal CrapNetto { get; set; }
        public string Charge { get; set; }
        public long StockPlace { get; set; }
        public string StockPlaceString { get; set; }
        public long ProcessStep { get; set; }
        public string ProcessStepString { get; set; }
        public string ContainerSeperation { get; set; }

        public long CustomerUnitAsLong
        {
            get
            {
                return CustomerUnit ?? 0;
            }
            set
            {
                if (value == 0)
                    CustomerUnit = null;
                else
                    CustomerUnit = value;
            }
        } 

        public long CustomerTpAsLong
        {
            get
            {
                return CustomerTp ?? 0;
            }
            set
            {
                if (value == 0)
                    CustomerTp = null;
                else
                    CustomerTp = value;
            }
        }

        public long ContainerAsLong
        {
            get
            {
                return Container ?? 0;
            }
            set
            {
                if (value == 0)
                    Container = null;
                else
                    Container = value;
            }
        } 

        public long ContainerWithoutAsLong
        {
            get
            {
                return ContainerWithout ?? 0;
            }
            set
            {
                if (value == 0)
                    ContainerWithout = null;
                else
                    ContainerWithout = value;
            }
        } 

        public bool IsValid
        {
            get
            {
                return Customer.HasValue &&
                    CustomerCrap.HasValue &&
                    !string.IsNullOrWhiteSpace(ContainerNumber);
            }
        }
    }

Nun würde diese ja nur die 3 Felder als Validierung prüfen.
Wie würdet ihr es bauen, wenn ihr mehr Felder prüfen wollt, diese sich aber erst zur Laufzeit ergeben, wenn der User seine Eingaben gemacht hat.
Einige Felder wären dann enabled = false und könnten demnach keine Werte enthalten.

Würde man hier mehrere isVAlid bauen, oder geht das anders?

Danke

Gruß
Daniel

Ralf Jansen · Verfasst: Mi 16.12.15 21:03

Zitat:

Würde man hier mehrere isVAlid bauen, oder geht das anders?

Eher nein. IsValid soll prüfen ob das Object ok ist oder nicht. Davon kann es nur eine Variante geben.
Wenn du aufgrund der UI irgendwas UI spezifisches machen musst dann gehört das da nicht hin.

Außer du hast ein spezielles Model für die UI das von dem Modell unterscheidbar ist das du zum persistieren verwendest. Wenn das also eine Model Klasse ist die spezifisch nur für diese UI geschrieben hast dann kannst du das da reinpacken.
Ansonsten wenn es eher ein klassisches Modell ist dann ist deren primäre Aufgabe das Persistieren und das Anwenden von Buisnesslogik. Und da gibt es nur die Variante gültig/nicht gültig egal woher das Object kommt, aus einer der diversen UIs (Desktop, Web, Mobil) oder aus einer Datenbank oder sonstwo her das muss egal sein.

Talemantros · Verfasst: Mi 16.12.15 21:14

Hallo Ralf
danke für die schnelle Antwort.
Also das Modell ist nur für diese UI geschrieben.

Kannst du mir Hilfestellung geben wie ich das dann da rein machen würde.
Habe gerade keine Idee dies umzusetzen?!

Danke

Gruß
Daniel

Ralf Jansen · Verfasst: Mi 16.12.15 21:25

Nenn die Bedingungen die du prüfen willst

Da ich die nicht kenne kann ich da jetzt auch keine Vorschläge machen.

Das was ich sagen kann wenn es von irgendwas abhängig ist, du sprachst von irgendwas enabled soundso, dann brauchst du diese als Property auch an der Klasse.

Talemantros · Verfasst: Mi 16.12.15 21:43

Also vielleicht nur als Beispiel hätte ich im UserControl eine Combobox, wo der Benutzer einen Behälter auswählen soll.
Je nach Schrottart könnte es sein, dass die Combobox "Behälter" sich enabled false macht und die Combobox "Ohne Behälter" sich zur Auswahl öffnet.

Die Propertys dazu in der Modellklasse wären

markieren

C#-Quelltext

1:
2:

        public long? Container { get; set; }
        public long? ContainerWithout { get; set; }

Es kann also immer nur eins der beiden enabled=true sein.
Da ich dies dann nicht über eine isValid machen könnte, wäre dies glaube ein gutes Beispiel, dass ich es mir mal angucken kann, wie man an so was ran gehen würde.

Danke

Gruß
Daniel

Ralf Jansen · Verfasst: Mi 16.12.15 21:50

Zitat:

Es kann also immer nur eins der beiden enabled=true sein.
Da ich dies dann nicht über eine isValid machen könnte, wäre dies glaube ein gutes Beispiel, dass ich es mir mal angucken kann, wie man an so was ran gehen würde.

Für IsValid heißt das dann für mich das du prüfen willst das genau eine von den beiden Properties gesetzt ist. Das ist doch leicht prüfbar?

markieren

C#-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:

public bool IsValid
{
    get
    {
        if ((container.HasValue && ContainerWithout.HasValue) ||   // beide gesetzt
            (!container.HasValue && !ContainerWithout.HasValue))   // keiner gesetzt
            return false;

        return Customer.HasValue &&
               CustomerCrap.HasValue &&
               !string.IsNullOrWhiteSpace(ContainerNumber);
    }
}

Talemantros · Verfasst: Mo 28.12.15 15:30

Vielen Lieben Dank,
ich weiß nicht wo es manchmal bei mir hängt.
Ich gehe immer viel zu kompliziert dran.

VG
Daniel

Palladin007 · Verfasst: Mo 28.12.15 16:00

Arbeitest Du mit WPF?
Ich habe bei meinem aktuellen Projekt folgenden Aufbau:

Eine ViewModel-Basisklasse, die Methoden wie GetValue und SetValue bereit hält. Die regelt dann auch das ganze mit PropertyChanged.
Diese Get- und SetValue-Methoden rufe ich dann im Getter und Setter der Properties auf. Die ViewModelBase-Klasse sammelt die Daten dann in einem Dictionary mit Name der Property als Key.
Außerdem implementiert die Klasse das IDataErrorInfo-Interface. Zusätzlich habe ich dort ein die Methode AddValidator, die den Property-Namen und eine Methode bekommt, die den Wert der Property validieren woll. Bei jedem SetValue geht die Klasse erst durch die gesammelten Validierungs-Functions durch und sammelt die Fehler-Meldung für diese Property. Erst danach wird der Wert gesetzt.

Die WPF-View bindet dann an eine Property und ändert fleißig den Wert. Gleichzeitig prüft sie bei jedem Ändern, ob dabei ein Fehler aufgetreten ist, dafür nutzt sie das IDataErrorInfo-Interface.
Standardmäßig gibt es bereits ein Error-Template, wie der Fehler angezeigt wird.

In dem Zuge ist vielleicht auch das INotifyDataErrorInfo-Interface ganz interessant, das kenne ich aber auch erst seit jetzt

Im ViewModel hast Du dann im Konstruktor eine Sammlung von AddValidator-Aufrufen, wo Du die Methoden übergibst, die die einzelnen Properties validieren. Die können dann auch schauen, ob eine Property überhaupt validiert werden soll oder darf. Du könntest dann z.B. noch eine boolean-Property halten, die dann fest legt ob eine andere bestimmte Property aktiv ist. Die View beobachtet diese bool-Property und kann dann beim false die betreffenden Felder deaktivieren.

Das mag auf den ersten Blick recht übertrieben wirken, aber ist meiner Meinung nach eine ziemlich sinnvolle Herangehensweise.
Außerdem mag ich den Gedanken nicht, dass irgendwelche Validierung in der View statt findet, schließlich soll die View nur anzeigen. Die Entscheidung, ob Daten korrekt sind, gehört meiner Meinung nach nicht dazu.
Außerdem lässt sich das gut in einer Basis-Klasse zusammen fassen.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme