Tweet
1. Validierung ist immer ein blödes Thema und es ist schwer diese an einem Ort zum Bündeln. Typischerweise macht man das aber als erstes bevor man in irgendeine andere Logik wie z.B. das Speicher in einer Datenbank geht. Analog zum EntryService könntest Du auch einen EntryValidator haben. z.B. in der Art:
Je nach Anforderungen kann man hier aber statt dem bool auch eine Liste von Validierungsergebnissen zurückgeben. Im einfachsten Fall z.B. Text:
Sowas in der Art könnte ich mir vorstellen. Je nachdem wie komplex Deine UI ist kannst Du den Rückgabewert der Validierung natürlich auch noch erweitern z.B. um zu erfahren welche Property genau nicht funktioniert hat um z.B. das direkt am dazugehörigen Steuerlement eine Fehlernachricht anzuzeigen.
2. Das sind automatic Properties. Diese werden standardmäßig mit dem default Wert des Typs gesetzt (in diesem Fall null). Das ist übrigens ein typisches Beispiel für Datencontainer/POCO/Entity. Die sehen in der Regel immer so aus.
3. Sie sollten sich so wenig wie möglich kennen. Das ist erstmal die goldene Regel. Aber Du solltest nicht auf biegen und brechen versuchen sie getrennt zu halten. Deswegen besser lieber die Logik immer erstmal runter tippen und schauen welche Teile man davon auseinander trennen kann. Als krampfhaft von vornherein zu versuchen alles auseinander zu ziehen und dann Code zu schreiben wo man Würgereiz bekommt wenn man das nächste mal rein schaut.
4. Ich würde niemals Integers die eine implizite Bedeutung haben als Rückgabewert verwenden. Dafür gibt es enums. Generell gilt meiner Meinung nach: Das Interface grundsätzlich immer so klein wie möglich halten. Das gilt für Eingabeparameter wie auch für Ausgabeparameter. Ich glaube das ist aber eine Geschmacksfrage wie jetzt genau welcher Rückgabewert auszusehen hat. Es ist natürlich auch möglich eine eigene Klasse nur für den Rückgabewert zu erstellen. In komplexeren Szenarien kann auch das eine Lösung sein. (Ich hoffe das war die Antwort auf die Frage, ich konnte nicht genau erkennen worauf Du Dich mit der Frage beziehst)
Code:
public class EntryValidator
{
public bool IsValid(Entry entry)
{
if(String.IsNullOrEmpty(entry.FirstName))
{
return false;
}
}
}
Code:
public class EntryValidator
{
public IEnumerable<string> FindValidationErros(Entry entry)
{
var errors = new List<string>();
if(String.IsNullOrEmpty(entry.FirstName))
{
errors.Add("Vorname fehlt");
}
return errors;
}
}
//In der Form
public class MyForm: Form
{
private readonly _entryValidator = new EntryValidator();
private readonly _entryService = new EntryService();
...
public void OnSaveButtonClick(...)
{
var entry = // entry aus UI holen - DataBinding oder per Hand
var errors = _entryValidator.FindValidationErros(entry);
if(errors.Any())
{
// gib Fehler an UI weiter
return;
}
_entryService.Save(entry);
}
}
2. Das sind automatic Properties. Diese werden standardmäßig mit dem default Wert des Typs gesetzt (in diesem Fall null). Das ist übrigens ein typisches Beispiel für Datencontainer/POCO/Entity. Die sehen in der Regel immer so aus.
3. Sie sollten sich so wenig wie möglich kennen. Das ist erstmal die goldene Regel. Aber Du solltest nicht auf biegen und brechen versuchen sie getrennt zu halten. Deswegen besser lieber die Logik immer erstmal runter tippen und schauen welche Teile man davon auseinander trennen kann. Als krampfhaft von vornherein zu versuchen alles auseinander zu ziehen und dann Code zu schreiben wo man Würgereiz bekommt wenn man das nächste mal rein schaut.
4. Ich würde niemals Integers die eine implizite Bedeutung haben als Rückgabewert verwenden. Dafür gibt es enums. Generell gilt meiner Meinung nach: Das Interface grundsätzlich immer so klein wie möglich halten. Das gilt für Eingabeparameter wie auch für Ausgabeparameter. Ich glaube das ist aber eine Geschmacksfrage wie jetzt genau welcher Rückgabewert auszusehen hat. Es ist natürlich auch möglich eine eigene Klasse nur für den Rückgabewert zu erstellen. In komplexeren Szenarien kann auch das eine Lösung sein. (Ich hoffe das war die Antwort auf die Frage, ich konnte nicht genau erkennen worauf Du Dich mit der Frage beziehst)
Comment