✔ Ich bräuchte mal etwas konstruktive Kritik

[Christian Kusmanow]

Hallo broetchen! Hi Reverent!

Ich würde die dritte Variante vorschlagen, Reverent.
Aber ihr müsst ein bissel abstrakter denken.
Die Primzahlen brauchst Du doch für irgendwas. Willst denke ich mal was damit berechnen.
Also stellen die dann quasi die Grundlage für deinen Vorgang dar.
Ich würde es daher in den Konstruktor der Klasse implementieren,
in der Du letztendlich die Berechnung durchführst.

Wenn Du innerhalb der Klasse threadgesteuert (System.Threading.Timer) berechnest,
könntest Du einfach via Event den Status deiner Berechnungen an dein Form reporten.
Die Daten kannst Du dem Event mit einer Klasse (von EventArgs abgeleitet) mitgeben,
welche die Datentypen oder Structs beinhaltet von denen Norbert gesprochen hat.

Im nachhinein kannst Du dann diese Klasse sonstwo weiterverwenden.

Mal ein anderes Beispiel:
Du hast Daten in deiner Config, die Du für deine Berechnugen brauchst.
Dann würd ich das auslesen in einer abstrakten Klasse implementieren
und dann der Klasse vererben, die die Daten braucht.

 

[NRFi]

Das soll heissen: Nutz die OOP und nicht so einen Wurschtelcode wie unter VB.

Hier gibts Leute, die auch mit VB.NET arbeiten und zwar genauso wie C#. Davon mal abgesehen wurde festgestellt, dass man mit VB.NET noch ein Tucken produktiver(schneller bei gleicher Qualität) ist als mit C#. OOP geht damit genauso gut.

Ok, ich mag auch lieber C#, aber VB ist deswegen kein Wurschtelcode (ab .NET jedenfalls)

 

[Christian Kusmanow]

mit VB.NET noch ein Tucken produktiver(schneller bei gleicher Qualität)

Es tut mir wirklich leid. Aber ich kann es aber trotzdem nicht lesen!

VB verleitet halt nun mal zu so einem Wurschtelcode.
Schau dir den code von den ganzen wanabe PHP coders an.

In nachhinein kann nur der "coder" was damit anfangen!

 

[broetchen]

Ich weiß jetzt nicht unbedingt, was Reverent machen will, aber wenn hinter der Primzahlenberechnung noch mehr steckt, würde ich auch eine "Bussines-Layer" einbauen.

Vor allem kommt es darauf an, wie groß das Projekt ist, das hier betrieben wird.
Wenn ich daheim für mich ein kleines Programm schreibe, dass höchstwahrscheinlich nicht den Frontend wechselt, bau ich auch max. 2 Layer ein und knalle das meiste dann doch ins Form und dessen Handler ;-)

mfg broetchen

 

[Christian Kusmanow]

So hab ich anfangs auch gedacht. Und als ich mehr draus machen wollte,
und irgend einen Fehler drinn hatte den ich nicht so richtig gefunden hab.
Musste ich doch wieder alles trennen um ihn zu finden.

Ausserdem ist das immer eine schöne Übung
Vielleicht reichts ja mehrere Klassen miteinander zu vererben.
Und schon Spaart man sich ne Menge Instanzierungs- und Aufruf-Code.

 

[NRFi]

Es tut mir wirklich leid. Aber ich kann es aber trotzdem nicht lesen!

ist halt eine andere syntax, deswegen. aber ich behaupte, dass mit .NET KEIN wurstelcode gemacht wird, sondern man genauso vernünftig sein Modell aufbauen kann, wie mit C#

VB verleitet halt nun mal zu so einem Wurschtelcode.

seh ich nicht so. Man kann zwar noch Module machen, aber das macht kein Mensch mehr ab .NET. Somit bist du quasi genauso an deine OOP gebunden, wie mit C#.
Ob du jetzt deinen Code in deinen Handling-Funktionen auf der Form packst, oder über Business- und Ressource-Access - Layers oder wie auch immer gehst, ist in den Haupt-.NET-Sprachen Sache des Entwicklers, nicht Eigenschaften der Sprache.

Schau dir den code von den ganzen wanabe PHP coders an.

wannabe != professionals

 

[Christian Kusmanow]

NRFi, das ist C#
Halte bitte unser nettes C# Forum von solchen polemischen VB Statments sauber.
Das kann man im NET Forum diskutieren!

wannabe != professionals

Was willst Du mir damit blos sagen? Das gleiche wie ich?

Fakt ist da man sich erstmal mit der OOP auseinandersetzen muss und wer begreift das schon am Anfang?
Bei welcher Sprache merkt man es am schnellsten das man, ohne OOP Kenntnisse, einfach nichts hinbekommt
und sich dadurch andauernd nur in Fuß schießt?
Genau.

 

[broetchen]

Aber zu viele Schichten gehen in die Performance.

Wir haben in der Schule einmal ein fettes Projekt (ein Online-Ticketing-System) durchgezogen (so richtig mit UML, RUP, ...) und dank des geilen Models durften wir keine Subselects und Joins in der DB-Schicht verwenden.

Wenn man bedenkt, wieviele Daten bei so einem System in der Realität sich in der DB herumtreiben, geht das dann ordentlich in die Knie, wenn man zuerst alle möglichen Sätze übers Netz an den Client jagen muss um dort dann 80 % wieder wegzuschmeißen ;-)

3 Schichten finde ich gut, was darüber hinausgeht, wird schon wieder unübersichtlich.

 

[Reverent]

Hallo Leute,
das mit der Primzahlen Berechnung war nur ein Beispiel.
Also halten Wir mal fest:
1. Wir entwerfen uns ein oder mehrere From(s)
2. Wir erstellen für jede Form eine Klasse, in der oder den Klasse kommen die Funktionen rein die z.B. beim Button_Click oder ListBox_SelectedIndexChanged u.s.w. ausgeführt werden und den globalen Variablen für die Form(s).
3. Eine Klasse mit allen zusätzlichen Funktionen und allen globalen Variablen die für das ganze Programm bestimmt sind.
4. Mit den Exception's habe ich jetzt noch keine Ahnung, aber Wir warten damal was Norbert so ausarbeitet. Danke nochmal, wäre echt cool wenn Du das machen würdest, Danke.
5. Eine Klasse für die Daten schreiben/lesen egal jetzt ob Datenbank, XML, Textdatei oder Rescourcedatei u.s.w.

Ich bitte um Verfolständigung, wenn jemand noch eine Idee hat!!

 

[Christian Kusmanow]

3 Schichten finde ich gut, was darüber hinausgeht, wird schon wieder unübersichtlich.

Du musst auch deinen Ausfürenden Layer trennen damit Du auch intern
klare Schnittstellen für die Daten hast und kannst im nachhinein evtl. nochwas wiederverwerten.
Im Endeffekt gibt aber die Notwendigkeit das Projekt vor.

Aber ich glaub ich wiederhole mich.
Schreibts mal ein Projekt mit 20.000 aktiven Zeilen (ohne Objekt initialisierungen)
und dann schaun'mer mal.