MVP - wie richtig auf die View zugreifen und Daten an Model?

Ralf Jansen · Verfasst: So 07.12.08 23:46

Dein MVP System finde ich jetzt so ok. Damit kannst du weitermachen und noch gute lenkend eingreifen wenn es für deine Zielanwendung nicht haargenau paßt ohne alles über den haufen werfen zu müssen.

Wenn dein Exceptionhandling nicht nur der einfachheithalber für dieses Beispiel so aussieht solltest du aber noch mal darüber nachdenken.

Nally · Beiträge: 46

Ralf Jansen hat folgendes geschrieben :

Dein MVP System finde ich jetzt so ok. Damit kannst du weitermachen und noch gute lenkend eingreifen wenn es für deine Zielanwendung nicht haargenau paßt ohne alles über den haufen werfen zu müssen.

Wenn dein Exceptionhandling nicht nur der einfachheithalber für dieses Beispiel so aussieht solltest du aber noch mal darüber nachdenken.

Danke, dass du noch geantwortet hast ;-)

In das Exception Handling für Entity Framework arbeite ich mich gerade ein und die msgbox war nur kurz für ein testzweck. Das Using werde ich letztendlich nicht benutzen, da der ObjectContext nicht disposed werden soll, da Single Thread Anwendung. Entweder benutze ich meine statische Singleton Klasse oder erstelle in jedem Presenter einen neuen Context. Beides ist ok. Danke nochmals, freue mich schon auf die nächste Frage ;-)

EDIT:

1.)Was würdest du denn noch ändern an den Exceptions?

2.)Nochmals wegen den Public Methoden in der Klasse deklariert im Interface. Wenn der Presenter die View kontrolliert in beide Richtungen, dann müssen diese Methoden ja public sein, welche die Daten anfordern/zurückgeben, denn nur private Methoden einer Klasse verbergen sich vor dem Zugriff von außen. Was für Methoden außer Events in der View würdest du dann als private deklarieren, wenn diese Methoden nicht von Außen aufgerufen werden sollen? Berechnungen an der View selbst die nichts mit der Business Logik zu tun haben?

Nally · Beiträge: 46

also so würde es passen für mich:

Die detaillierte Exception vor der allgemeinen exception. Was würdest du sonst noch ändern?

markieren

C#-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:

  private void View_AddDepartment(String departmentName)
        {
            DEPARTMENT department = new DEPARTMENT();

            try
            {
                department.department_name = departmentName;
                mycontext.AddToDEPARTMENT(department);
                mycontext.SaveChanges();
                queryDepartment.Execute(MergeOption.AppendOnly);
                view.DataToBindingSource(queryDepartment);
            }
            catch (UpdateException ex)
            {
                Console.WriteLine("Error: " + ex.StackTrace);
                MessageBox.Show("Die Abteilung: " + departmentName + " existiert bereits", "Fehler!", MessageBoxButtons.OK, MessageBoxIcon.Exclamation);
            }
            catch (Exception ex)
            {
                Console.WriteLine("Error: " + ex.StackTrace);
                MessageBox.Show("Ein unerwarterer Fehler ist aufgetreten und das Programm wird beendet", "Fehler!", MessageBoxButtons.OK, MessageBoxIcon.Exclamation);
                //Programm beenden... + Ressourcen freigeben
            }            
        }

Ralf Jansen · Verfasst: Di 09.12.08 23:53

Fange Exceptions nur wenn du auch weißt wie du die Exception behandeln sollst. Ansonsten lass sie einfach durchfallen. Wenn kein Exceptionblock diese fängt dann kommt spätestens der globale Exceptionhandler und wird diese anzeigen und dann die Anwendung beenden. Nur visualisieren für den User ist für also kein Grund eine Exception zu fangen.

Die UpdateException zu schlucken und das fehlschlagen des updates anzuzeigen mag noch richtig sein das fangen der Standard Exception ist aber sicherlich falsch. Da gehört ans Ende zumindest noch ein throw rein damit nach dem Anzeigen die Exception weitergeworfen wird und damit irgendwer eine sinnvolle Exceptionbehandlung vornimmt oder eben, falls nicht anders möglich, die Anwendung sicherheitshalber beendet wird. Besser einfach den Block für die Standard Exception weglassen.

Nally · Beiträge: 46

Zitat:

Die UpdateException zu schlucken und das fehlschlagen des updates anzuzeigen mag noch richtig sein das fangen der Standard Exception ist aber sicherlich falsch.

Das muss ich ja anzeigen, sonst weiß der user ja nicht warum er keine 2 gleiche Departments erstellen kann, ist ja so in der Datenbank definiert sprich departmentname als Primary Key.

Jetzt bin ich mir unsicher ob ich darüber auch noch einen neuen Thread machen soll...naja ich wills net ausufern lassen:

Wenn ich den gleichen departmentname eingebe der in der Datenbank existiert kommt die Fehlermeldung, dass das department bereits existiert. So weit so gut. Gebe ich danach aber departments ein die nicht existieren, bekomme ich weiterhin die Meldung, dass das department bereits existiert ? Wie kann das sein?

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme