Was ist eine bessere Möglichkeit, ein einfaches Datenbankauswahl-/Aktualisierungsprogramm in vb6 zu implementieren?

Question

ok hier ist der Rhabarber - Ich arbeite an einer Anwendung, die in VB6 geschrieben wurde (in dem ich weniger als 1 Monat Erfahrung habe), und der Kern der Anwendung ist eine einfache Datenbank Auswahl/Update Art der App.

Im Grunde können Sie nur nach Mitarbeitern suchen (Datensatz aus der Datenbank auswählen) und ihre Daten bearbeiten (und die Datenbank aktualisieren).

Nun, die Art und Weise, wie dies in der Codebasis, die ich geerbt habe getan wird, ist durch eine gottlose Anzahl von gottlosen großen SQL-Abfrage Zeichenfolgen. Hier ist eine nicht-wirklich-made-up-aber-verändert schützen the unschuldig Beispiel dafür, was ich spreche:

'Post Transaction to Database 
If actionToDo = "Change" Then 
    Set coffeeTableRS = jawsTheSQL.Execute("Update coffeeTable set Name = '" & txtName.text & "', OriginalName = '" & MOriginalName & "', Prefix = '" & txtPrefix.text & "', FName = '" & txtFName.text & "', MName = '" & txtMName.text & "', LName = '" & txtLName.text & "', Suffix = '" & txtSuffix.text & "', Relationship = '" & txtRelationship.text & "', " & _ 
     "Addr1 = '" & txtAddr1.text & "', Addr2 = '" & txtAddr2.text & "', StreetNumber = '" & txtStreetNumber.text & "', StreetName = '" & txtStreetName.text & "', City = '" & cboCity.text & "', State = '" & ChkNull(cboState.text) & "', ZipCode = '" & ChkNull(txtZipCode.text) & "', ZipCode2 = '" & ChkNull(txtZipCode2.text) & "', " & _ 
     "Birthdate = " & MBirthdate & ", SSN = '" & Trim(txtSSN1.text & txtSSN2.text & txtSSN3.text) & "', OccuCode = '" & currentOccupationCode & "', OccuValue = " & currentOccupationValue & ", ChangeDate = '" & Format(MDate, "yyyy/mm/dd hh:mm:ss") & "', Active = '" & IIf(chkActive.Value = vbChecked, "", "I") & "'" & _   
     " where IDnumber = '" & txtIDNumber.text & "'") 

Und es ist eine dieser für jede Aktion, die wir übernehmen können (hinzufügen, bearbeiten, löschen usw.)

Mit anderen Worten, als ich gebeten wurde, ein einfaches Kontrollkästchen Steuerelement auf das Hauptformular, das all dies behandelt, hinzuzufügen, musste ich es in etwa 15 verschiedenen Orten hinzufügen. Ich musste es all diesen Abfragen hinzufügen, um sicherzustellen, dass es beim Datensatzabruf abgerufen und auf Datensatz gesetzt wurde, sowie das Flag für den Vergleich der Daten mit "true" gesetzt wurde, wenn der Status des Kontrollkästchens nicht mit dem Status des Datensatzes übereinstimmte .

Also ich bin auf der Suche nach all diesem Denken "es hat GOT zu einem besseren/leichteren/wartungsfreundlicheren Weg, dies zu tun."

Ich weiß praktisch nichts über VB6, aber gibt es eine Möglichkeit, eine einfache Auswahl/Update-Datenbank-App mit einer gut aussehenden GUI zu machen (dh wir können dem Client nicht einfach ein editierbares DataGrid geben und sagen "here you go, es hat alles, was Sie brauchen "), wo die Steuerelemente automatisch an die Datenbank gebunden sind (ich vermute über Felder mit dem gleichen Namen), und das Update kann auch leicht gehandhabt werden (da es im Grunde nur" Steuer-Name foo mit Wert füllen von Datenbank-Feld mit dem Namen ‚foo‘)?

Was der VB6 best-Practice-Weg ist, so etwas zu tun? ist es wesentlich leichter in einer Sprache wie C# getan?

Vielen Dank im Voraus

Edit: aktualisiert basierend Spezifikationen Antworten auf gegeben

• muss ein eigenständiges sein .exe

Answer 1

MS Access für diese Art der Anwendung ist perfekt, solange es ein relativ niedrig sein Anzahl der gleichzeitigen Benutzer.

Answer 2

Ich schätze, Sie wollen die Anwendung nicht umschreiben? Die Abfrage, wie sie geschrieben wird, ist schlecht geschrieben. Nicht sicher, warum der Entwickler es so geschrieben hat. Es sollte Parameter verwenden. Aber jeder "gute" Entwickler kann schlechten Code in jeder Sprache schreiben.

Answer 3

Um ehrlich zu sein, müssen Sie 2 Dinge tun.

1. Informieren Sie diejenigen, die Besitz haben, dass diese Anwendung vollständig nicht erreichbar ist. Nehmen Sie alle erforderlichen Änderungen so sorgfältig wie möglich vor. Versuchen Sie nicht, es zu einem besseren Ansatz umzuformen.

2. Informieren Sie diejenigen, die Eigentümerschaft haben, dass sie eine erneute Schreiboperation benötigen (in diesem Fall sollten Sie sich von VB6 entfernen).

Wenn diese Aktionen durch das Management nicht getroffen werden weiterhin Ihre besten mit der aktuellen App zu tun, aber nicht Refactoring, sondern aktualisieren Sie Ihren Lebenslauf, den Rest kennen Sie.

Answer 4

Ich würde zu einem neueren Technologie-Stack verschieben; aber hey, wenn das nicht möglich ist ... da es aussieht, als ob Sie bereits ADO verwenden, sollten Sie getrennte Recordsets verwenden.

Im Allgemeinen, was Sie tun möchten, ist das Re-Cord-Set mit einer Verbindung öffnen, legen Sie die Verbindung Re-Cord-Sets zu nichts. Bearbeiten Sie das Re-Cord-Set (es kann für beliebig lange Zeit hängen bleiben), erhalten Sie dann eine neue Verbindung, und legen Sie die Re-Cord-Sets-Verbindung zu es fest. Dann aktualisieren Sie den Stapel. eine Weile :)

Answer 5

Es gibt viele verschiedene Ansätze, die ich bin mir ziemlich sicher, dass Sie diesen Datensatz an einen Datagrid binden können, aber hey, es ist schon:

Dies ist ein guter Ausgangspunkt: http://www.devguru.com/features/tutorials/DisconnectedRecordsets/tutDisconnRS.asp

bearbeiten Aber von wo Sie gerade sind, hier ist was ich tun würde:

1) Für jedes Formular, machen Sie eine einzelne Routine, die dieses Formular basierend auf Schlüsselinformationen, die an es übergeben werden. 1b) Ändern Sie den eingebetteten Ladecode, um stattdessen diese Routinen aufzurufen.

2) Machen Sie dasselbe für Formularaktionen, um neue Datensätze (Inserts) zu erstellen und Datensätze zu löschen.

3) Machen Sie dasselbe für Updates, außer dass es mehr als eine Art von Aktualisierung geben kann, so dass Sie möglicherweise mehrere pro Formular/Tabelle benötigen. Diese bilden nun Ihre Datenzugriffsroutinen für ein Formular/eine Tabelle: Laden (Auswählen), Hinzufügen (Einfügen), Entfernen (Löschen) und ÄndernX (Aktualisieren (x)). Sammeln Sie alle diese in einem eigenen Modul oder einer eigenen Klasse: {form} _DBAccess. Zu diesem Zeitpunkt sollte in keinem der Formulare oder Geschäftslogikmodule noch Embedded SQL vorhanden sein.

4) Gleichzeitig ändern Sie Ihre Datenzugriffsroutinen, um stattdessen gespeicherte Prozeduren oder Embedded SQL zu verwenden. Erstellen Sie einfach eine entsprechende gespeicherte Prozedur (QueryDef für Access DB), und kopieren Sie die eingebettete SQL-Anmeldung. Ändern Sie dann den vb6-Code, um stattdessen die gespeicherte Prozedur aufzurufen.

Answer 6

Kurz gesagt, gelten MVC, und in diesem Fall: Split-Ansicht von Daten.

Ich würde eine Employee-Klasse tun, die alle diese Felder der Tabelle zusammen mit einer Update-, Einfüge- und Löschmethode (etwas wie eine Entität in Hibernate/JPA). Dann hätten Sie im Formular 2 Funktionen zum Laden und Speichern der GUI-Felder von/zu den Klassenfeldern/Eigenschaften (wie Sie möchten). Jede Benutzeraktion (Hinzufügen, Bearbeiten, Löschen, ...) würde dann dieses Mitarbeiterobjekt über die GUI-Speicherfunktion ändern und das Aktualisieren, Einfügen oder Löschen aufrufen. Vielleicht brauchen Sie einige andere spezielle Update-Funktionen, ich weiß es nicht.

Ich würde sagen, es sollte nicht mehr als 1 Tag dauern, um den Mitarbeiterteil auf diese Weise zu refaktorieren und Sie werden eine saubere Trennung von GUI und Daten erhalten. Sie werden auch frei von den Abhängigkeiten der GUI-Elemente in Ihrem SQL und möglicherweise von einer anderen involvierten Logik sein.

Ich benutze diesen Ansatz auch und es ist flexibel und stabil genug.

Answer 7

Auch eine Jet-MDB unterstützt parametrisierte gespeicherte Prozeduren von ADO. Abgesehen davon, dass Sie häufig vorbereitete Abfragen verwenden können. Mit diesen beiden Techniken können Sie die SQL-Anweisung von der prozeduralen Aktivität in Ihrer Programmlogik trennen und die SQL-Injection (absichtlich oder versehentlich) reduzieren.

Sie könnten auch in Betracht ziehen, datengebundene Steuerelemente zu verwenden, die eher einer Access-Anwendung ähneln, aber das hat seine Schwächen und wäre ohne Zweifel eine wichtige Neuschreibung.

Der MVC-Ansatz hat seine guten Seiten, kann aber übertrieben sein und führt oft zu einem großen, verwirrenden und schwierig zu wartenden Objektmodell. Es muss oft auf eine unreine Art und Weise erfolgen, bei der Methodenaufrufe über Friend-Eigenschaften oder -Methoden Nebenwirkungen in anderen Objekten haben. Dies ist in der Regel der Fall, da es sich nach der Umwandlung in einen Arbeitsspeicher nur schwer ändern kann, da Benutzer die Geschäftsregeln im Laufe der Zeit verfeinern und das Objektmodell das Geschäft nicht mehr ordnungsgemäß modelliert. Für Anwendungen mit einem kurzen Lebenszyklus könnte dies der richtige Weg sein.

Es kann auch dort gut funktionieren, wo es keine einzelne Benutzerschnittstelle gibt, d. H. Vielleicht eine Web-UI, eine Desktop-UI und "alternative Service Delivery" -UIs (IVR, öffentlich zugängliche Webanwendungen usw.). Ich habe eine Anwendung, bei der ich aus diesem Grund einen MVC-Ansatz gewählt hätte: ein GUI-Programm, das nun auch im Batch- oder Befehlszeilenmodus laufen kann.