Laden...

Wie speichert man eine Gruppe von Radiobuttons in eine Variable Best Practice

Erstellt von wydy vor 8 Jahren Letzter Beitrag vor 8 Jahren 1.289 Views
W
wydy Themenstarter:in
8 Beiträge seit 2012
vor 8 Jahren
Wie speichert man eine Gruppe von Radiobuttons in eine Variable Best Practice

Moin,

die Frage wird sich recht banal anhören, führte jedoch bereits zu einer grösseren Diskussion bei ein paar Kollegen. Deswegen wollte ich hier mal kurz nach eurem Input nachfragen.

Ich habe ein einfaches Form mit einer Gruppe von drei Radiobuttons. Der User kann einen der Buttons auswählen und mittels "senden" das Formular abschicken. Also einfach eins zwei oder drei 😃

Die Frage ist jetzt, wie speichere ich die Variable sauber ab, was ist hier das Best Practice. Die Idee ist, dass ich die Benutzereingabe an das Backend weiterleite und dort verarbeite. Ich möchte also meine Usereingabe in einer einfachen Variable speichern und ans Backend weiterleiten. Theoretisch rech simpel und in ein paar Minuten eigentlich ausprogrammiert.

Jetzt meine Frage, mit was für einem Variablentyp würdet ihr arbeiten?
int -> war auch meine erste Idee, aber der nächste Programmierer wird sich dann Fragen was ist 1, 2 und was 3? Ich kann höchstens mit Kommentaren das ganze leserlich machen, aber auch das ist nicht sehr elegant.
string -> zwar leserlich, jedoch müsste ich das ganze im Backend parsen. Jeder Tippfehler führt zu einem Problem und technisch gesehen ist es langsamer. In der heutigen Zeit zwar vernachlässigbar, aber da das Backend evtl. auf einem anderen Server und läuft mittels SOAP/Rest läuft doch nicht die Lösung.
enum -> Wollte ich eigentlich verwenden. Aber ich hätte dann ja für jeden Radiobutton ein globales enum und irgendwann ein Share Projekt mit mehreren Hundert enums und niemand weiss mehr genau, welches enum jetzt für was ist.
Alternativ könnte ich auf beiden Seiten private enums verwenden. Aber dann müsste ich das ganze wieder parsen und in jeder Klasse müsste ich das enum neu deklarieren.
bool -> Ich habe eine Gruppe von Radioboxen als eine Information mit drei Zuständen, oop technisch also nicht ganz sauber mehr. Auch würde ich drei Variablen über die Schnittstelle senden und Methodenaufrufe sollten eigentlich nicht zu viele Parameter haben.

Wie gesagt, eigentlich ein banales Problem und trotzdem gab es eine riesen Diskussion darüber und bisher noch nicht DIE Lösung. Wie würdet ihr das ganze angehen? Ich werde wahrscheinlich einen Int verwenden und mittels Kommentar die Stati angeben.

1.696 Beiträge seit 2006
vor 8 Jahren

IMHO ist enum der geeigneteste Kandidat für solche Werte/Konstanste, da man sehr schön durch den Namen beschreiben kann, was/wofür der Wert ist. In WinAPI siehst du auch eine Menge davon und jeder kommt damit zurecht.

Ich bin verantwortlich für das, was ich sage, nicht für das, was du verstehst.

**:::

W
wydy Themenstarter:in
8 Beiträge seit 2012
vor 8 Jahren

IMHO ist enum der geeigneteste Kandidat für solche Werte/Konstanste, da man sehr schön durch den Namen beschreiben kann, was/wofür der Wert ist. In WinAPI siehst du auch eine Menge davon und jeder kommt damit zurecht.

Vor einem Jahr hätte ich dir noch ohne zu zögern zugestimmt. Dann hatte ich eine Zeit lang aber ein grösseres Projekt zum anpassen wo genau das Thema so behandelt wurde. Dort gab es ein Share Projekt mit 2-3 Enum Klassen und total bestimmt über 200 Enums definiert. Es wusste keiner mehr welches enum wo eingesetzt wird. Klar kann man die Usage finden, trotzdem ist es alles andere als übersichtlich. Auch wenn du im Fakturamodul 20 Enums hast, irgendwann gehen dir die aussagekräftigen Namen aus. Seither bin ich etwas zurückhaltend bei einem enum.

Es geht mir hier nicht um explizite Daten, welche auch in der Datenbank gespeichert werden. Also bspw. den Zivilstand einer Person oder den Status einer Rechnung/Lieferung. Sondern um eine einfache Gruppe von Radiobuttons, welche nur in einem Formular eingesetzt werden und im Businesslayer sagen, wie ein Prozess verarbeitet werden soll. Der enum wird also nie mehr irgendwo anders verwendet werden.

1.696 Beiträge seit 2006
vor 8 Jahren

Ähm, man muss natürlich Vorschriften für die Benamsungen zuerst definieren, BEVOR man sich dran macht enum anzulegen. z.B. MS hat WM für window message definiert, etc. und darauf bauend kann man per Abkürzungen die Einsatzbereiche definieren; der letzte Part wird dann die eigentliche Wertbeschreibung sein.

Ich bin verantwortlich für das, was ich sage, nicht für das, was du verstehst.

**:::

W
wydy Themenstarter:in
8 Beiträge seit 2012
vor 8 Jahren

Ich habe jetzt glaube ich eine halbwegs brauchbare Variante gefunden um mein Problem anzugehen.

Ich definiere mein enum innerhalb der Businessklasse. Jetzt je nach Architektur ist das ganze recht simpel.

Greift das GUI direkt über ein eigenes Object auf die Businessklasse zu kann ich einfach:
Businessklasse.Enum verwenden.
Geht das ganze über ein Interface wird es etwas komplizierter, ich würde dort aber mein enum beim Interface anlegen. Innerhalb der Inferfaceklasse funktionier es leider nicht ganz.

Selbst wenn ich die Logik in mehreren Businessklassen verwende kann ich so auf das Enum zugreifen.

So habe ich zwar ein globales enum, es ist aber nicht in einem Share definiert und das Projekt ist weiterhin übersichtlich. Wie gesagt, das enum wird ja nur auf 2 Layern verwendet und nicht global, also möchte ich es nicht unbedingt in eine globale enumklasse ablegen.

Trotzdem danke für die Hilfe 😃

2.207 Beiträge seit 2011
vor 8 Jahren

Von der Architektur her ist ein Shared-Projekt mit allen Enums auch nicht das wahre. Leg es so nah wie möglich an den Ort, wo es gebraucht wird. Aber wenn ein Projekt das Enum nicht braucht, sollte es auch nicht davon wissen.

Gruss

Coffeebean

W
wydy Themenstarter:in
8 Beiträge seit 2012
vor 8 Jahren
Hinweis von Coffeebean vor 8 Jahren

[Hinweis] Wie poste ich richtig? Punkt 2.3 Keine Full-Quotes

Von der Architektur her ist ein Shared-Projekt mit allen Enums auch nicht das wahre. Leg es so nah wie möglich an den Ort, wo es gebraucht wird. Aber wenn ein Projekt das Enum nicht braucht, sollte es auch nicht davon wissen.

Danke genau das war auch mein Gedanke. Hier noch ein vereinfachtes Beispiel wie ich das ganze implementieren würde(Die Connection Klasse wäre in der Endlösung nicht mehr statisch und das Interface würde ich in einem weiteren Schritt noch in ein Share auslagern.). Akzeptable Lösung?


namespace ConsoleApplicationTest
{
    class Program
    {
        static void Main(string[] args)
        {
            Connection.BusinessClass.MyMethod(ConsoleApplication2.Status.Status1);
        }
    }
}

namespace ConsoleApplicationTest
{
    public class Connection
    {
        private static IMyBusinessClass businessClass;

        public static IMyBusinessClass BusinessClass
        {
            get
            {
                if(businessClass == null)
                    businessClass = new MyBusinessClass();
                return businessClass;
            }
        }
    }
}

namespace ConsoleApplication2
{
    public interface IMyBusinessClass
    {
        int MyMethod(ConsoleApplication2.Status status);
    }

    public enum Status
    {
        Status1,
        Status2,
        Status3
    }
}

namespace ConsoleApplication2
{
    public class MyBusinessClass : IMyBusinessClass
    {
        public int MyMethod(ConsoleApplication2.Status status)
        {
            return (int)status;
        }
    }
}

Ich hätte das enum gerne noch innerhalb des Interface das ist aber technisch ja nicht möglich.