...
Haben alle Klassen mindestens ein Title-Layout?
Reichen die Informationen aus dem Title-Layout aus um das Objekt klar zu identifizieren?
Haben alle Klassen die in einer Liste angezeigt werden mindestens ein List-Layout?
Reichen die Informationen in den List-Layouts aus um die Objekte zu identifizieren und um die wichtigen Vergleiche zwischen den Objekten anzustellen?
Haben alle Klassen für die ein Detail angezeigt wird mindestens ein Detail-Layout?
Sind die Informationen im Detail-Layout sinnvoll sortiert und gruppiert?
wichtige Infos zuerst?
Sind zusammengehörige Infos in nahe beieinander?
Falls zu viele Infos für einer Seite, Tabs eingesetzt?
Sind die Detail-Layout im Vergleich mit anderen Detail-Layouts konsistent beschriftet und aufgebaut?
Werden je nach Status/Datenlage unnötige Felder ausgeblendet?
Sind nur dort Captions definiert wo es auch wirklich nötig ist?
Werden wo möglich bestehende Captions/PluralCaptions von Klassen verwendet?
Code: Werden die Layouts in der Reihenfolge Title, List, Detail definiert?
Regeln für Code Strukturierung
Aufbau Builder Datei
AddClasses
AddPaths
AddProperties
Code Style
Builder wird im Fluent API erstellt. Für die Bessere Lesbarkeit
Builder.Add.Xxx... Add mit auf der Builder Zeile
Danach weitere Enrichments auf neue Zeile
Reihenfolge Enrichments Daten Nahe am DB wichtiger und oben
Eher Oben
Id
Transient
IsNotNullable
Default
Eher runter
Visibility
Captions
Immer gleiche Reihenfolge - konsistent z.B. 1. en 2. de
keine doppelte Leerzeilen. Wenn nötig evtl. noch Kommentar über Abschnitt
AddClasses
HauptKlasse
Liste von Enumns
Add Paths
Add.PathRelation -> fügt Relation Property + Path ein
Add Properties
Text immer mit Länge
Reihenfolge - Alle nacheinander
Properties, CalculatedProperties
Actions, Sorts, Index
Breadcrumbs