Laden...

Wie kann ich Daten, bevor ich sie über ein UI in die DB absende, validieren?

Erstellt von Menten vor 6 Jahren Letzter Beitrag vor 6 Jahren 4.458 Views
M
Menten Themenstarter:in
7 Beiträge seit 2018
vor 6 Jahren
Wie kann ich Daten, bevor ich sie über ein UI in die DB absende, validieren?

Hallo zusammen,

ich habe mich gerade hier im Forum angemeldet weil ich Hilfe beim Umstieg von Delphi auf C# suche. Mit Delphi arbeite ich seit vielen Jahren, sehe die Enticklung bei Embarcadero aber mitlerweile kritisch, insbesondere was das Vertriebsgebahren und die Preise angeht.

Ich habe mich auch schon redlich bemüht, mich in C# einzuarbeiten, habe Kurse besucht und Bücher gewälzt. Was mir allerdings fehlt, ist die Leichtigkeit mit der ich in Delphi Anwendung zu Verwaltung von Daten entwickeln kann. Durch die gebundenen Controls wird einem viel Arbeit abgenommen. Datentypen und Feldgrößen sind bekannt und werden berücksichtigt.

Ich habe extra einen C# Datenbank-Kurs besucht. Da ich der einzige Teilnehmer war und keine Datenbank-Grundlagen zu vermitteln waren, hätte der Dozent sicher Zeit gehabt. Aber nach zwei Tagen hatten wir uns in den ADO-Eingeweiden verlaufen, in der Kommandozeile und ohne jeden Praxisbezug. Meine Fragen z.B. zur Verwendung von Stored Procedures zur Speicherung von Daten bzw. der Konfiguration von Abfragen im Designer und spätere Anpassung der Query lösten nur Unverständnis aus. Oder die Antwort "dass hat Microsoft so nicht vorgesehen".

Klar kann ich Daten anzeigen und speichern. Ich habe mir (in WinForms) auch erarbeitet, wie ich eine Abfrage im Designer aufbaue und hinterher den "Where-Teil" bearbeite.

Wenn ich allerdings meinen Kunden Anwendungen liefere, bei denen sie zuerst alles eingeben können um dann beim Speichern auf die Fehler hingewiesen zu werden, fragen die mich, ob ich noch alle Latten am Zaun habe. Zumindest meine Kunden erwarten, dass Fehleingaben möglichst garnicht erst gemacht werden können.

Ich weiß, dass ich das teilweise über Bindungen machen kann, z.B. die Feldgröße. Aber das muss ich dann alles von Hand machen.

Deswegen meine Frage: Wie löst ihr dieses Dilemma?

Gibt es keine Komponenten-Sets, die diese Bindungen mitbringen? Überhaupt finde ich nur wenige zusätzliche Komponenten (von den Major Playern DevEpress usw. mal abgesehen). Suche ich falsch?

Danke für jede Hilfe!
Stefan Menten

1.029 Beiträge seit 2010
vor 6 Jahren

Hi,

hm - das klingt fast so als ob VisualStudio LightSwitch was für dich wäre wenn es generell um so simple Anwendungen geht, dass diese halb aus dem Datenbankschema generiert werden können.

Nun denn - das was du von C# erwartest bzw. vom .NET-Framework wirst du so denke ich nur von sehr stark spezialisierten Firmen bekommen oder schlicht selbst bauen - das Thema ist:
ADO.NET ist nicht ausschließlich für den Einsatz in WindowsForms gedacht - es wird genauso gut auf der Konsole, WPF, Web, etc. eingesetzt. Dort einen "Converter" anzubieten, der Steuerelemente (die es ja nicht einmal unbedingt geben muss) klingt eher halbgar für mich. Denn selbst wenn die Datenbankvorgaben eingehalten werden - ist dein Objekt ja noch lange nicht korrekt.

Da scheint Delphi einen trügerischen Schein zu erwecken...

Prinzipiell:
Grundlegend so wirklich pur direkt mit ADO.NET ist fast schon selten im Einsatz. Man nimmt oder baut gerne einen ObjectRelationalMapper - meist in Verbindung mit Repository-Pattern und UnitOfWork-Pattern - baut daraus seine Daten-Schicht. Die Daten-Schicht wird widerum nur von der Business-Schicht angesprochen, welche auch dazu verpflichtet wäre Eingaben vollständig zu validieren (und nicht nur auf Längen zu prüfen) - die Oberfläche kann (und sollte) durchaus auch solche Prüfungen machen - aber die hat normalerweise keine direkte Abhängigkeit zur Datenschicht - geschweigedenn zur Datenbank.

Ab davon:
Was du erzählst klingt wie gesagt recht simpel gehalten - wenn du den üblichen Weg so nicht gehen möchtest - wäre es sicher gar nicht so kompliziert sich beispielsweise auf Basis des EntityFrameworks abgeleitete Controls zu schreiben und diese so aufzumotzen, dass diese Klasse und Property einer Entity bekommen und entsprechend automatische Basisvalidierungen durchführen können.

StoredProcedures:
Bin zwar kein Profi - aber was ich so gehört habe sind die so langsam verpönt, da hier Logik aufgesplittet und verteilt wird.

LG

M
Menten Themenstarter:in
7 Beiträge seit 2018
vor 6 Jahren

Hallo Taipi88,

warum sollten Stored Procedures verpönt sein? Man benutzt zum Schreiben Stored Procedures und zum Lesen Views. Tabellen sind für den Benutzer grundsätzlich nicht zugänglich. Außerdem legt man die Business Logik damit zentral in der Datenbank ab.

Wenn die Oberfläche, wie du schreibst Prüfungen machen soll, wie macht sie sie denn? Wenn ich eine Textbox an ein Integer-Feld binde, kann der User eingeben was er will. Das ist ja genau mein Problem. Selbst wenn ich ein Schichtenmodell aufbaue (oder das EntityFramework nehme), weiß das Control nicht was in ihm steckt.

Wie machst du das denn in deinen Anwendungen? Lässt du den User eingeben was er will und beim Speichern gibts du die Fehler zurück, unter Umständen für mehrere Datensätze?

Danke und Gruß
Stefan

16.806 Beiträge seit 2008
vor 6 Jahren

Man benutzt zum Schreiben Stored Procedures und zum Lesen Views.

Nein.

Stored Procs sind verpöhnt.
Die Nachteile überwiegen mittlerweile deutlich dem Nutzen.

Nachteile (es gibt viel mehr!), die heute viel relevanter sind als 1980:

  • Stored Procs führen zum Flaschenhals der Performance, weil sie nicht skalierbar (und oft auch nicht parallelisierbar) sind
  • Logik gehört nicht in die Datenbank
  • Stored Procs können nahezu Null in ordentliche Software Tests gepackt werden ( [Artikel] Unit-Tests: Einführung in das Unit-Testing mit VisualStudio )
  • Du bist extremst an eine Engine (und manchmal sogar Version) gebunden
  • Stored Procs gehören zum spezialisierten Wissensstand, was moderne Mixed Teams komplexer machen. Und Fachkräfte mit komplexem Stored Proc wissen zu bekommen ist nicht trivial; jedoch i.d.R. teurer. (Bus factor)
  • Quellcode-Management mit Stored Procs mischen ist ein absoluter pain in the ***
  • Refaktorierung von Code wird extremst erschwert
  • User direkt auf die DB zu lassen um SPs auszuführen und damit die Datenbank zu im Netzwerk exposen, ist ein potentielles, zusätzliches Sicherheitsrisiko
  • Der Einsatz von SPs verhindern oft ein mögliches Verwenden von skalaren Caching-Pattern in Applikationen

Die Vorteile wie zB. den Access auf Tabellen zu verbieten und nur Stored Procs zuzulassen ist hinfällig, da ein Access Management nicht in die Datenbank gehört, sondern in die Business Logik und damit zB. in einem Service Layer in eine Applikation.
Moderne Authentifizierungsverfahren können auch nicht in Datenbanken verwendet werden; sie unterstützen sie ganz einfach nicht (und werden es auch nicht).

Außerdem legt man die Business Logik damit zentral in der Datenbank ab.

Und genau da gehört Logik nicht hin. Absolut nicht. Gar nicht. Zero.

F
10.010 Beiträge seit 2004
vor 6 Jahren

@Menten:
Ihr redet an einander vorbei.

INotifyPropertyChanged, IEditableObject und IDataErrorInfo sind 3 Interfaces die es seit Anbeginn im FW gibt,
die genau dafür gedacht sind.

Deine DTO und auch die BO enthalten die Logik der Validierung.
Jede Oberflächentechnologie von MS ( WinodowsForms/WPF/Web ) behandelt diese Interfaces um fehler anzeigen zu können.

Wir haben hier im Forum hunderte von Beispiele dazu.

Also Herangehensweise:

  1. Benutze einen OR-Mapper.
  2. Erweitere deine DTO um Validierungen die hier wirklich benötigt werden.
  3. Erstelle BO's die sich validieren können, am Businesscase orientiert.
  4. Benutze entsprechende Kontrols und DataBinding.

Wenn du es mal verstanden hast, ist das alles in wenigen Minuten für Datenbanken implementiert.
Incl. Eingabevalidierung und allem.

D
985 Beiträge seit 2014
vor 6 Jahren

Wenn man eine Datenbank-Oberfläche erstellen will, dann mag dieser Ansatz mit SP, View sowie alle Logik in der Datenbank richtig sein.

Ich erstelle allerdings Anwendungen wo am Anfang noch gar nicht feststeht, welche Datenbank dort zum Zuge kommt. Festgelegt wird das ziemlich zum Schluss und manchmal stellt man fest, dass keine Datenbank die richtige Lösung ist.

Databases are details to be hidden. They are not your central abstraction, nor are they the core of your application. Ever. Uncle Bob Martin

Delphi hat allerdings mit dem RAD Ansatz und den DataAware-Komponenten viele Entwickler auf das falsche Pferd gelockt und selbige es willig angenommen, weil es ja so hübsch einfach und schnell ist. 5 Klicks und die Anwendung sieht schon zu 90% fertig aus.

1.029 Beiträge seit 2010
vor 6 Jahren

Hi,

@Menten - die von dir genannte Vorgehensweise widerspricht so ziemlich allem was ich gehört und gelernt habe.

Grundsätzlich hat zwar Abt genug zu deiner Vorgehensweise geschrieben - aber um dir mal einen anderen Blickwinkel zu verschaffen: Wenn du mir (User) nicht mehr bieten kannst wie Datenbanklogik - warum sollte ich dann noch dein Programm verwenden?

Obendrauf kommt durchaus die Wahl der Datenbanktechnologie. So wie ich zu entwickeln versuche - hat meine Oberfläche nicht den geringsten Schimmer:
a) mit welcher Implementierung der Business-Schichten gearbeitet wird
b) mit welcher Implementierung der Daten-Schicht gearbeitet wird

Das hat schlicht den Vorteil, dass wenn mir mein Chef morgen sagt - du - ich hab keine Lust mehr die MSSQL-Lizenzen einzusetzen - machst du das bitte mit PostgreSQL oder MySQL - dann sage ich: Jo - muss zwar eine neue Implementierung der Daten-Schicht schreiben - aber - die Logik die bereits den Realitätstest bestanden hat muss ich nicht einmal anfassen. (Kam bei mir schon mehrfach vor, dass eine Funktionaltität die zuerst nur intern benötigt wurde - dann auch dritten zur Verfügung gestellt werden muss - und da sind die unternehmenstypischen Anforderungen eben andere)

Zudem kommt - wenn du ehrlich bist - gesetzt der Fall du hast wirklich jede Logik in SP's - wie soll denn dein Delphi-Control wissen, welche Speziallogik die Gültigkeit des Feldes bestimmt? Delphi ist ja wohl kaum in der Lage die SP derart zu analysieren...

Was die Validierung von Objekten angeht - die korrekten Schnittstellen wurden hier bereits genannt - das kann durchaus so umgesetzt werden, dass:
a) Entweder keine ungültigen Werte zugelassen werden
b) Noch bevor die Datenschicht angesprochen wird fehlerhafte Felder rot markiert und mit entsprechenden Verbesserungshinweisen versehen werden - gibt zur Umsetzung dieser Schnittstellen auch wieder zig verschiedene Vorgehensweisen.

Validierung (in der Oberfläche) z.B. in WPF ist bei mir mehrschichtig - zum einen setze ich die korrekten Controls ein(meist ehrlich gesagt Fremdprodukte), die spezialisiert auf double/integer/whatever sind, Minimal-und Maximallängen haben und ggf. eine entsprechende Eingabemaske haben. (Im einfachsten Fall die MaskedTextBox) -> Das ist der Part wo semantisch geprüft wird ob die einzelnen Werte für sich ok sind. (Falls hier was nicht passt - wird bereits die Eingabe verweigert)

Zudem prüfe ich auch im Business-Objekt ebenfalls z.B. die Längen (doppelt - zugegeben - aber ich möchte meine Business-API gerne so haben, dass man möglichst wenig Ärger hat, selbst wenn man die Oberfläche austauscht) - und eben auch die logische Korrektheit. (Ausgabe dann wie bereits von anderen genannt z.B. über IDataErrorInfo)

LG

M
Menten Themenstarter:in
7 Beiträge seit 2018
vor 6 Jahren

Hallo zusammen,

danke erst mal für die rege Anteilnahme.

@Taipe88, die Vorgehensweise mag nicht en vogue, kommt aber nicht von mir. Hatte ich schon als konkrete Kundenanforderung im Projekt. Das Schichten-Modell kenne ich natürlich auch.

Aber, jedes Projekt ist anders. In meinem aktuellen bin ich als Consultant in einer Firma ohne irgendwelche eigene Entwicklungskapazitäten und bereite die Einführung eines PDM vor. Das heißt ich bin Datenbank-Admin, Datenbank-Entwickler, Software-Entwickler und alles andere auch. Ich sammle Daten aus verschiedensten Quellen und versuche den Usern erst mal überhaupt Datenbank gestützt Werkzeuge an die Hand zu geben. Es steht auch nicht zur Debatte ob irgendwann eine andere Datenbank verwendet werden könnte weil die Anwendung nach der Einführung nicht mehr gebraucht wird.

Delphi analysiert auch nicht die SPs. In der Regel habe ich eine SP für jede Tabelle die dann Insert/Update und ggf. Delete übernimmt, bediene die in der Anwendung also immer gleich. Es kann aber auch vorkommen, das ich in der Anwendung nur eine Abfrage habe, in der Datenbank mit einer SP mehrere Tabellen bediene.

@Sir Rufo, es geht um eine reine Datenbank-Oberfläche und die Anwendungen die ich so erstelle laufen performant und stabil. Die sind natürlich nicht für die Vertragsverwaltung bei der Allianz gedacht.

@Abt, ich gebe dir in allen Punkten recht wenn es um kompexe Anwendungen in komplexen Umgebungen geht. Aber die Nummer mit den Kanonen und den Spatzen ist dir bekannt?

Noch mal @Taipe88, was nimmst du denn für Fremdprodukte? Das war doch meine eigentliche Frage.

Danke und Gruß
Stefan

16.806 Beiträge seit 2008
vor 6 Jahren

Kanonen und Spatzen entschuldigt oder gar begründet das nicht.
Man kann auch korrekt kleine Tools entwickeln.

D
985 Beiträge seit 2014
vor 6 Jahren

Ich denke hier geht es um etwas ganz anderes.

Du (@Menten) versuchst den dir bekannten Delphi-Way mit C# zu beschreiten. Kann ich insofern nachvollziehen, weil du das gewohnt bist und damit dann schneller zum Ziel kommst, welches hier sowieso nur eine begrenzte Lebensdauer hat.

Meine ehrliche Empfehlung daher: Setz es mit Delphi im Delphi-Way um.

M
Menten Themenstarter:in
7 Beiträge seit 2018
vor 6 Jahren

Den Delphi Way würde ich das nicht nennen. C# bringt ja alles mit um genauso auf Daten zuzugreifen. Das Dataset ist ja nichts anderes. Ich konfiguriere meine Datenbank-Objekte und binde sie an die Oberflächen-Objekte.

Und das war meine eigentliche Frage. Wie ich die Oberfläche so anbinde, das der User keine Eingaben machen kann, die hinterher nicht in die DB passen. Das Problem habe ich doch unabhängig davon wie der Datenbank-Zugriff erfolgt.

Der Delphi Way sind da die gebundenen Oberflächen-Elemente. Der C# Way kann es aber doch nicht sein, für jedes Eingabefeld von Hand Bindungen und Validierungen zu programmieren.

Gruß
Stefan

D
985 Beiträge seit 2014
vor 6 Jahren

Doch, denn was taugt eine Lösung, die nur halbgar ist?

Nehmen wir mal ASP.NET MVC als Beispiel. Da definiert man sich für jede (Eingabe-)View ein ViewModel (reines DTO) und legt über Attribute die grundlegenden Validierungen fest.

Im Controller werden dann weitere Validierungen vorgenommen, die sich nicht (oder nur umständlich) per Attribute definieren lassen.

Sind diese Validierungen alle in Ordnung, dann werden die Daten vom ViewModel an einen Service gereicht, der sich um die Persistierung kümmert (wahrscheinlich eine Datenbank).

Wie man sieht, ist das Konzept völlig losgelöst von irgendwelchen Datenbanken, DataSets, whatever, weil gar nicht sicher ist, ob man eine Datenbank hat.

3.003 Beiträge seit 2006
vor 6 Jahren

Und das war meine eigentliche Frage. Wie ich die Oberfläche so anbinde, das der User keine Eingaben machen kann, die hinterher nicht in die DB passen. Das Problem habe ich doch unabhängig davon wie der Datenbank-Zugriff erfolgt.

Uh. Ich bin ein bisschen fasziniert davon, dass es es so eine Herangehensweise noch gibt; zuletzt habe ich dieses GUI-Entwicklungsparadigma im TeamDeveloper 2000 (aus eben jenem Jahr) von Gupta/Centura gesehen. Und diese Oberflächen waren träge, unflexibel, konnten nur auf einer bestimmten Datenbank laufen (deren Struktur man um Himmels Willen nicht anrühren durfte) und benötigte einen Heidenaufwand, um die Datenbank so vorzubereiten, dass das Programm dann auch lief. Im Wesentlichen war das nichts anderes als MS-Access-Masken für Fortgeschrittene.

Der Punkt ist der: die Datenbank speichert deine Daten. Sie kennt deren Form nicht, sie kennt deren Bedeutung nicht, sie kann auch nicht validieren, ob ein Datensatz gespeichert werden kann (wenn der Typ stimmt). Nichts davon. Und weil sie das nicht wissen kann und auch nicht wissen soll (!!), ist sie auch nicht in der Lage, irgendwem mitzuteilen, wie die Oberfläche auszusehen hat, die "korrekte" Daten erzeugt. Ja, Erstimplementierungen von Oberflächen, wenn man es richtig macht, brauchen etwas Zeit: Validierungen wollen geschrieben werden, eventuell braucht man Controls, und so weiter und so weiter. Allerdings gibt es für beides Schnittstellen, die das Leben leichter machen. Dazu kommt, dass man im Lauf der Zeit eine eigene Bibliothek aus Basisforms, Validierungen und Controls erhält. Unser ERP hat irgendwas im deutlich vierstelligen Bereich an Oberflächen, und eine neue Stammdateneingabe inklusive Validierung zu erstellen, ist eine Sache von 5-10 Minuten.

Du müsstest dafür allerdings deine Komfortzone verlassen und die Art und Weise, wie du bisher Datenbanken und Oberflächen entwickelt hast, hinter dir lassen. Ansonsten gilt, was FZelle gesagt hat.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

W
872 Beiträge seit 2005
vor 6 Jahren

Ich kann Menten's Problem schon verstehen, bei WPF/Winforms gibt es sehr viele verschiedene Wege, wie man Datenbank-Oberflächen programmieren kann.
Da muss man selber den eigenen Weg finden, was am Anfang einiges an Zeit kostet und eine gesunde Mischung zwischen reiner Lehre und praktischem Aufwand sein soll. Dazu sollte man sich mit Dingen wie Fody und einem MVVM Framework wie ReactiveUI oder MVVM Light beschäftigen, damit man möglichst wenig Arbeit hat. Da findet man auch die besten Beispiele zum Nachbauen.

D
985 Beiträge seit 2014
vor 6 Jahren

@weismat

Grundsätzlich sollte man sich von dem Gedanken verabschieden eine Datenbank-Oberfläche zu erstellen, denn genau daher kommt die Denkweise, dass sich alles um diese Datenbank dreht.

M
Menten Themenstarter:in
7 Beiträge seit 2018
vor 6 Jahren

Das ist jetzt aber eine typische Forumsdiskussion, in der jemand eine Frage stellt und dann eine bizarre Grundsatzdiskussion losbricht, die an der eigentlichen Frage vollkommen vorbei geht.

Mit dem Teamdeveloper habe ich auch schon gearbeitet, das ist wirklich ein Graus. Wir haben das dann durch eine flotte Delphi Anwendung ersetzt.

Ich habe auch schon mit Poet und Caché gearbeitet falls das noch jemand kennt. Wurde auch als die Zukunftstechnologie beworben. OO-DB, Client/Server, NoSQL, MVC, MVVM, usw. usw. Alles das Beste seit der Erfindung von geschnittenem Brot. Was kommt morgen? Ideologen der Welt vereinigt euch.

Vor Jahren hat man versucht, Systeme zu entwickeln, die selbstständig Anwendungen entwickeln. Innerhalb von wenigen Jahren sollten die alle Entwickler überflüssig machen. Ihr erklärt mir jetzt das Gegenteil. Erst mal ein Modell entwickeln und dort alles reinschreiben (was in der Datenbank-Struktur schon drin steht). Und zwar unabhängig davon, wie komplex die Anwendung ist.

Ist es zwangläufig richtig, eine Technologie für eine 1000-Oberflächen-Anwendung auf jede andere Anwendung anzuwenden, unabhängig von der Komplexidität?

Meine Komfortzone ist im allgemeinen sehr klein weil ich nämlich freiberuflich arbeite, und ich hatte sie verlassen und wollte zu C# wechseln. War wohl eine dumme Idee.

Schöne Grüße an den Tellerrand, falls ihr ihn mal seht!
Stefan Menten

T
461 Beiträge seit 2013
vor 6 Jahren

Das ist jetzt aber eine typische Forumsdiskussion, in der jemand eine Frage stellt und dann eine bizarre Grundsatzdiskussion losbricht, die an der eigentlichen Frage vollkommen vorbei geht.

Sehe ich nicht so. Das sind Grundsatzfragen die du hier gestellt hast und die in der heutigen Zeit in einer professionellen Anwendung keine Anwendung mehr finden.

Hier wird nicht über wem hergefallen, hier wird Klartext gesprochen, daß ist auch ein grund, warum ich noch hier bin und wahrscheinlich bleiben werde. (Solang mich keiner blockt oder rauswirft 😉 )

Ich habe den Titel mal angepasst, so dass Suchende auch etwas damit anfangen können. EDIT: Ich sollte beim Wort "Shift" im Titel das "f" nicht vergessen... 😄

5.657 Beiträge seit 2006
vor 6 Jahren

Warum argumentierst du so destruktiv?
Du hast doch eine Menge unterschiedliche Antworten auf deine Frage bekommen. Dir wurde empfohlen, mit Delphi wie vor 15 Jahren weiterzuarbeiten, dir wurde empfohlen, mit C# und DataSets wie vor 15 Jahren weiterzuarbeiten, dir wurde empfohlen, kommerzielle Anwendungen für deine Zwecke einzusetzen, und dir wurde empfohlen, mit C# auf dem aktuellen Stand der Anwendungs-Entwicklung zu arbeiten. Jeder versucht halt, aus seiner Sicht zu argumentieren, um dir weiterzuhelfen. Was ist daran bizarr? Was hast du denn noch erwartet?

Weeks of programming can save you hours of planning

T
2.219 Beiträge seit 2008
vor 6 Jahren

@Menten
Meiner Meinung nach solltest du deine Konzepte von Delphi verwerfen und dich auf aktuelle Konzepte von C# konzentrieren, wenn du wirklich C# nutzen willst.
Wenn du aber mit C# nicht zu frieden bist oder an den Delphi Konzepten hängen willst, dann bleib dabei.
Programmiersprachen sollten wie Werkzeuge betrachtet werden und immer für den passenden Zweck verwendet werden.
Wenn Delphi für deine Zwecke besser ist als C#, dann bleib bei Delphi.
Du solltest dich nicht zwingen C# zu nutzen, wenn es für dich nicht der richtige Ansatz ist.

Ich will hier keine Grundsätzlichen Fragen klären, was die heutige bessere Vorgehensweise wäre.
Ich würde, da ich Delphi nicht wirklich kenne, auch den C# Weg nehmen auch wenn der Weg länger und auch aufwändiger wäre.

Ob man damit am Ende mehr Probleme bekommt oder nicht, kann ich leider nicht genau beurteilen.
Wenn deine Kunden auch noch auf bestimmte Abläufe bestehen, was ich nur bedingt nachvollziehen kann, dann solltest du schauen was bzw. wie du es umsetzen kannst.

Ich würde aber eben auch den langen Weg nehmen und die gesamten Prozesse im Code meiner Anwendung abbilden.
Gerade aus den Vorteilen daraus, die sich schon aus einfachen Dingen wie Caching und co. ergeben, würde ich es so machen.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

M
Menten Themenstarter:in
7 Beiträge seit 2018
vor 6 Jahren

Vielleicht wenn ich meine urspünglich Frage noch mal weiderhole:

Wie kann ich in der Oberfläche sinnvoll falsche Benutzereingaben verhindert ohne für jedes Control von Hand Bindungen oder sonst was zu programmieren. In der Oberfläche, also vor dem Schreiben wo hin auch immer.

Als Beispiel habe ich die gebundenen Controls von Delphi angeführt weil die eben über das Datenbankfeld wissen, welcher Datentyp zu handhaben ist.

Ansonsten verwende ich Konzepte, die C# mir anbietet. Mag sein, das ich beim nächsten Mal anders arbeite als mit einem ADO Dataset. Ich Moment möchte ich aber eine schlichte Datenbankoberfläche mit wenigen zu pflegenden Tabellen in einer vernünftigen Oberfläche abbilden.

Wenn meine Antworten destruktiv erscheinen, mag das daran liegen, dass ich erschrocken bin über das Ausmass an Schwarz-Weiß-Denken das ich hier vorfinde wenn man tatsächlich die Anforderungen eines ERP mit meiner Frage in einen Topf wirft oder annimmt, jede x-beliebige Anwendung müsste auch mit jedem x-beliebigen Datenspeicher zusammen arbeiten können. Oder Stored Prodedures für verpönt erklärt weil man dafür Spezial-Wissen braucht.

Ich bin offen für Anregungen und Kritik und erkenne durchaus die Probleme die meine Vorgehensweise haben kann. Aber was hier geschrieben wird, beantwortet meine Frage nicht. Und die Anforderung, falsche Eingaben zu unterbinden, hätte ich auch mit jedem anderen Konzept.

4.931 Beiträge seit 2008
vor 6 Jahren

Für das Verhindern/Anzeigen falscher Eingaben gibt es für WinForms den ErrorProvider. Unter Validate user input in Windows Forms gibt es eine Validator-Komponente, welche das Setzen der Eigenschaften schon zur Design-Zeit erlaubt. In Kombination kannst du dir dann Steuerelemente erzeugen, welche spezialisiert sind (z.B. Nummernfelder, E-Mail, Passwort, ...).

Und für WPF (MVVM) gibt es ähnliche Konzepte:
Input Validation using MVVM Pattern
Validating User Input - WPF MVVM

3.003 Beiträge seit 2006
vor 6 Jahren

Was sind "falsche Eingaben"? Ich kann prinzipiell jede Benutzereingabe nehmen und in die Datenbank schieben.

Das einfachste ist: benutz das Control, das nur die Art Eingaben zulässt. NumericUpDown für Zahlen, DatePicker für Datumsangaben, Textbox für Text, Checkbox für bool.

Dann kannst du dir syntaktische Validierungen zumeist sparen. Um semantische Validierung kommst du nicht herum. Die Anforderung, dass in Spalte "c" von Tabelle "xy" nur Zahlen stehen dürfen, die nach Uhrzeit eines bestimmten Client-Rechners bei Vollmond den Wasserstand in Köln darstellen, wenn dieser auf eine Primzahl endet, musst du nach wie vor von Hand machen, weil das Datenbanken eben nicht abbilden können.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

1.029 Beiträge seit 2010
vor 6 Jahren

Hi,

dann gehe ich nur mal auf die Controls ein.

Einsatzbar wären:
DevCompoments DotNetBar
Syncfusion
Telerik
DevExpress
(und sicher noch zig andere)

Soweit ich weiß bieten alle entsprechende Controls um das ganze aufzuhübschen an - des Weiteren haben die Controls i.d.R. bereits die nötigen Limitierungsmöglichkeiten eingebaut.
(Min, Max, etc.)

Was davon am Besten zu dir passt wirst du selbst schauen müssen, da teils erhebliche Unterschiede hinsichtlich Preis, Funktionsumfang und Support geboten werden. Alternativ gibt es mit einer gezielten Suche oder ggf. eigenen kleinen Erweiterungen durchaus auch selbst die Möglichkeit entsprechende Funktionalität durch Ableitung in die Controls zu bringen.

LG

D
985 Beiträge seit 2014
vor 6 Jahren

Wie kann ich in der Oberfläche sinnvoll falsche Benutzereingaben verhindert ohne für jedes Control von Hand Bindungen oder sonst was zu programmieren.

AFAIK gibt es da nichts (von VS out of the box)

5.657 Beiträge seit 2006
vor 6 Jahren

Was bedeutet denn überhaupt:

von Hand Bindungen oder sonst was zu programmieren.

Kannst du da ein bißchen konkreter werden? Willst du keine Bindungen, willst du nicht programmieren, oder soll das alles vollautomatisch funktionieren? Woher soll denn deine Oberfläche wissen, welche Daten sie akzeptieren soll, ohne daß du es irgendwo vorher festlegst?

Weeks of programming can save you hours of planning

M
Menten Themenstarter:in
7 Beiträge seit 2018
vor 6 Jahren

Von Hand meint im Quellcode mit einer Prozedure Bindungen anzulegen um z.B. um MaxLength zu setzen. Und zwar um keine hart-codierten Werte im Quelltext zu haben bzw. um Änderungen im Datenmodell soweit es geht automatisch zu berücksichtigen.

Ich habe jetzt mal mit dem ErrorProvider etwas herum probiert. Damit könnte man glaube ich arbeiten. Über die DataBindungs kann man das Feld herausfinden, an das gebunden ist und darüber Typ, Größe usw. ermitteln. Muss ich mal eine Nacht drüber schlafen.

An die großen Control-Suites habe ich auch schon gedacht. Mit DevExpress arbeite ich unter Delphi. Soweit ich das gesehen habe, gibt es dort bei den .net-Controls aber auch keine speziellen gebundenen Controls. Den Rest muss ich mir mal genauer ansehen.

Danke erst mal für die Hilfe
Stefan Menten

M
184 Beiträge seit 2012
vor 6 Jahren

Die DevExpress-Controls z.B. berücksichtigen schon von Haus aus DataAnnotations, z.B. so unter WinForms: https://documentation.devexpress.com/windowsforms/18273/Common-Features/Data-Binding/Data-Annotation-Attributes

Wenn du also deine Datenklassen (oder ViewModels) designst, kannst du je nachdem welche Technologie du verwendest den einzelnen Properties (an die du ja später bindest) schon entsprechende DataAnnotations mitgeben, so dass der User schon mal z.B. zu lange Texte gar nicht erst eintragen kann.

Meine persönliche Erfahrung: Die DevExpress-Controls zusammen mit WPF und gescheitem MVVM passen gut zusammen. Das ViewModel bestimmt dort über DataAnnotations, welche groben Einschränkungen die View für die jeweiligen Properties umsetzen soll.