Wie organisiere ich repetitiven Code?

Mein Team erstellt viele einmalige Webformulare. Die meisten dieser Formulare senden nur eine E-Mail, und einige schreiben einfach eine Datenbank.

Derzeit befindet sich jedes Formular in einer eigenen Lösung in Visual Studio Team Foundation Server. Das heißt, wir haben fast 100 verschiedene Formularprojekte, was es schwierig macht, die Konsistenz aufrechtzuerhalten. Jede Form ist insofern einzigartig, als die Felder unterschiedlich sind, aber alle machen fast dasselbe.

Ich versuche, diese irgendwie zu verdichten, und ich könnte wirklich eine Anleitung gebrauchen.

• Sollte ich versuchen, eine Lösungsdatei mit allen darin enthaltenen Formularprojekten zu erstellen? Es gibt nicht viel Installationscode, obwohl ich einige Hilfsklassen erstellen könnte, um bei der E-Mail-Formatierung und dergleichen zu helfen. Es wäre sehr hilfreich, CSS, JavaScript, Steuerelemente und Bilder projektübergreifend freigeben zu können.
• Gibt es angesichts der Tatsache, dass wir ein Microsoft-Shop sind, konkrete Vorteile für MVC gegenüber Webforms für dieses spezielle Szenario? Ich bin vom Konzept von MVC als Ganzes begeistert, aber würde es mir helfen, ein Datenerfassungsformular mit 15 Feldern effizienter zusammenzustellen, wenn dieses Formular nur eine E-Mail senden würde? In dem Formular, in dem ich darüber nachdachte, war ein gutes Stück Logik eingebaut, um Felder basierend auf den Antworten des Benutzers anzuzeigen und auszublenden, und es scheint, als wäre die Verwendung von MVC und jQuery weniger effizient gewesen.

Ein sicheres Re-Factoring ohne Tests ist schwierig und voller Gefahren.

Ich würde beginnen mit:

• Schreiben von Testfällen, die die verschiedenen Arten der Eingabe in diese Formulare und die erwartete Ausgabe abdecken. Es hört sich so an, als würde dies nicht allzu lange dauern, da Sie der Meinung sind, dass die meisten dieser Formulare in ihrer Funktionalität identisch sind oder nahe daran liegen.

• Führen Sie diese Testfälle für die rund 100 Formulare aus (aktivieren Sie die Codeabdeckung, um die Codepfade zu verfolgen).

Danach können Sie sehen, was Sie sicher wieder herausrechnen können, und dann können Sie (ein Beispiel):

• Führen Sie Ihr Tool zur Erkennung von Codeduplikationen aus (nicht sicher, wie es in .NET heißt, in Java haben wir CPD). Entfernen Sie sofort 13 identische Formulare. Führen Sie jetzt die Tests erneut aus - Yay! Sie alle bestehen bis auf Formular 11, OK, daher können wir das noch nicht löschen.

• Entfernen Sie den gesamten lokalen E-Mail-Formatierungscode und rufen Sie alle Formulare an, um ein gemeinsames E-Mail-Verarbeitungsmodul aufzurufen. Führen Sie Tests durch, alle bestehen bis auf eines, hhmmm OK .... UTF-8-Zeichen, beheben Sie das im generischen Modul, führen Sie Tests erneut aus, yay wir sind alle gut!

spülen und wiederholen.

Ich würde vorschlagen, den Einreichungsteil zu abstrahieren. Fügen Sie mit Model / View / Controller die Formulare in die Ansicht ein und lassen Sie sie denselben Controller verwenden. Dieser Controller kann entweder eine allgemeine Aktion ausführen, z. B. eine E-Mail an eine Standardadresse senden, oder die Formulardaten an einen Controller umleiten, der dies kann. Auf diese Weise müssen Sie zum Erstellen eines neuen Formulars lediglich das Formular erstellen und die Ausgabe an diesen Controller weiterleiten. Diese Archetektur könnte in einem einzigen Projekt enthalten sein, mit dem Sie CSS und Javascript wie erwähnt freigeben können.

Um die Formatierung der E-Mails zu handhaben, würde ich zunächst einen generischen Formatierer erstellen, beispielsweise einen, der nur die Namen und Werte der Formularelemente sowie den anderen Metdatentyp wie die übermittelte Zeit usw. auflistet. Sie können dies so ausgefallen gestalten, wie Sie möchten . Wenn Sie dann wirklich mehr benutzerdefinierte Handhabung benötigen, fügen Sie eine Fabrik hinzu. Die Fabrik würde eine Formatierungsschnittstelle zurückgeben. Innerhalb der Factory können Sie dann nach einem Formatierer für dieses bestimmte Formular suchen oder das generische zurückgeben, wenn kein bestimmtes vorhanden ist. Dieses Design würde auch das Testen von Einheiten des Steuergeräts vereinfachen, da Sie leicht einen Scheinformatierer für Testzwecke bereitstellen könnten.

Übrigens würde ich die E-Mail-Adresse nicht als Argument aus dem Formular einfügen. Wenn Sie an mehrere Adressen senden müssen, würde ich vorschlagen, eine Nachschlagetabelle zu haben, die alle Formulare und die E-Mail enthält, an die sie gesendet werden sollen. Dies könnte in XML oder in Code implementiert werden (ich habe beide gesehen, obwohl ich nicht sicher bin, ob beides besser ist). Auf diese Weise vermeiden Sie, dass Spammer Ihre E-Mail-Adressen von der Formularseite abrufen.