Frage zu Dependency Injection

[das-d]

Ich beschäftige mich zur Zeit mit Dependency Injection. Nun ich habe das Codeproject Beispiel gemacht dass Threading etc. ermöglicht und als Beispiel die Logon Prozedur abbildet. Nun meine Frage wie muss ich das Paradigma ausweiten wenn ich jetzt nach dme Login dann weiter machen will?

Sprich ich führe das LogonView aus und habe erfolgreich einen Login durchgeführt. Aber wie schaffe ich es nun dass danach wieder etwas passiert. Wer ist verantwortlich dass die Anwendung weiß der Login war erfolgreich. Welches Element startet weitere Operationen?

Ich hoffe es ist klar was ich meine?

Mit freundlichen Grüßen

daniel

[gfoidl]

Hallo Daniel,

ich kann aus der Frage keinen Zusammenhang mit Depency Injection erkennen. Du beziehst dich auf ein Codeproject-Beispiel - kannst du den Link posten? Dann kann ich mir das Bsp anschauen.

Für Depency Injection siehe auch: http://entwickler-forum.de/showthrea...587#post202587


mfG Gü

[das-d]

Hier der Link zum Projekt

Also wenn ich meine LogonProzedur auf diese Weise starte. Dann ergibt sich mir jetzt noch nicht wie ich es zu Implementieren habe wenn ich nach dem Login entscheiden will wie es weiter geht. Also wenn ich einen Login meiner Hauptanwendung vorschalten will. Wie ist da die Vorgehensweise mit Dependency Injection. Da die einzelnen Teile sozusagen ja nichts von einander wissen.

[fanderlf]

Ich denke du solltest einfach nicht so starten wie die das in diesem Programm tun.

So etwas wie ein ApplicationController wäre wohl das was Du suchst.

Beim starten der Anwendung holst Du dir einen IApplicationController aus dem DI Container. Dieser hat wieder eine Referenz auf den ILogonView (dieser wird dann ebenfalls aus dem DI Container geholt) und dieser holt sich dann den ILogonController aus dem DI Container.

Ein ApplicationController sieht dann im einfachsten Fall etwa so aus:

[highlight=c#]
public class ApplicationController:IApplicationController
{
private ILogonView _logonView;

public ApplicationController(ILogonView logonView) //Constructor Injection
{
_logonView = logonView;

_logonView.ShowModal();

if( _logonView.LoginSuccessfull ) // Diese Property müsste man noch hinzufügen -> kann aus dem Notify Event berechnet werden
{
//weiterer Programmablauf
}
else
{
//Programm schließen
}
}
}
[/highlight]

Ich hoffe Du kansnt Dir grob vorstellen was ich meine du brauchst quasi noch ein "Wrapper"-Objekt um Deine Anwendung was den Ablauf der Anwendung steuert. Hier könntest Du z.B. auch das Command Pattern reinbauen um Undo/Redo funktionalität zu haben

[das-d]

ich hab mir fast so etwas gedacht. Also dass ein Container um das ganze nochmal des Rätsels Lösung sein würde. Danke für die HIlfe

[das-d]

jetzt hat sich doch noch eine Frage ergeben. Die View ist ja eigentlich nur für die Anzeige da. Ist es denn dann pragmatisch Korrekt dass mir die View an den ApplicationController zurückgibt ob der Logon erfolgreich war oder nicht?

[fanderlf]

An genau so einer Frage hänge ich auch momentan. Ich habe mich schon gefragt ob es in Windows Forms Anwendungen nicht sinniger ist den Presenter als "oberstes" Objekt zu instanziieren.
Ich hänge z.B. gerade an dem Problem, dass ich ein anzuzeigendes Objekt habe. Dieses muss auf irgendeinem Weg in den Presenter.

Eventuell versuche ich es mal so:

[highlight=c#]
public class MyPresenter
{
public MyPresenter(IMyView view, MyDataClass myDataObject)
{
view.SomeThingHasChanged += ViewSomeThingWasChangedHandler;
}

private void ViewSomeThingWasChangedHandler(object sender, EventArgs e)
{
//Do Something
}
}

public interface IMyView
{
//some view properties

//some view events
event EventHandler SomeThingHasChanged;
}

public MyView:IMyView
{
public MyView()
{

}
}
[/highlight]

In C# muss der View den Presenter meiner Meinung nach sowieso nicht kennen, weil ich für alles was der View tut Events verwende. Ich finde das übersichtlicher als gegenseitig irgendwelche Funktionen aufzurufen. Ausserdem entspricht es imho auch mehr der Natur der Sache.
Ich sehe nicht warum der View eine Referenz auf den Presenter bräuchte (und selbst wenn kann man den Presenter auch noch in das IView interface mit aufnehmen).

[das-d]

Ja mir erscheint der Presenter auch sinniger. Vielleicht werd ich auch so umdenken. Ich meine der Presenter zeichnet sich dadurch aus dass er ViewSchnittstelle und Logikschnittstellen kennt. Allerdings muss man sagen dass es dann nicht mehr möglich wäre View etc auszutauschen. Denn wenn man es so macht muss der Presenter in der Lage sein die View anzuzeigen. Was heißt man muss die View in eine Form Casten --> das heißt aber auch dass das ganze nicht mehr universell für ASP pages umsetzbar wird ...

bin sehr verwirrt. Aber in die View kann die LogonProperty nicht weil ich sonst in der View Code bräuchte um das Ergebnis des Logins zu berechnen und dass ist nicht sinn und zweck von MVP

[fanderlf]

Naja... Du könntest ja das LogonProperty durch den View an den Presenter deligieren. Schön ist aber was anderes...

jaja... wenigstens gehts nicht nur mir so

Wenn Du magst können wir uns ja mal auf einen Chat verabreden. Ich hab momentan auch noch so einige Probleme die ich nicht gebacken bekomme. Eventuell hilfts ja wenn wir uns etwas austauschen

[fanderlf]

Mir ist gerade noch eine Idee gekommen. Eigentlich solltest Du ja im MVP irgendwo eine Model Klasse haben die den LoginStatus repräsentiert. Und ich denke man sollte diese später verwenden um den Zustand des Logins abzufragen.
Allerdings hast Du dann auch das Problem, dass Du diese Login Klasse irgendwie in den Presenter bringen musst.
In den Beispielen die ich gesehen habe hatte der Presenter immer einen Dal (der sich ja ganz einfach per DI einschleusen lässt) und hat dann vom View die anzuzeigende Id abgefragt. Allerdings möchte ich nicht, wenn ich das Objekt schon habe mir das gleiche wieder aus der DB holen müssen. Macht irgendwie nicht viel Sinn.

[das-d]

hmm das wäre noch eine Möglichkeit aber auch das wiederstrebt mir irgendwie ... naja mal gucken wäre natürlich die Alternative ich erzeuge mir eine Klasse die den Eingeloggten User Repräsentiert mit all seinen Eigenschaften
- vorname
- nachname
etc.
und einer Property die zurückgibt eingeloggt oder nicht allerdings ist dann wieder folgendes zu überlegen --> die Property darf nur einen getter enthalten somit muss sich diese Klasse wieder selbst um den Login kümmern was auch wieder bedeutet mann muss wieder klären wie diese Klasse mit den ganzen richtigen datenzugriffsschichten in Verbindung tritt.

[fanderlf]

das ist wohl der springende Punkt... wie schaff ichs ein Datenobjekt vorbei am View in den Presenter zu bekommen.
Irgendwie bräuchte man da einen Caching Mechanismus... aber mein Gefühl sagt mir, dass das auch irgendwie anders gehen muss. Nur wie ist die Frage

Ich hatte mir schon sowas überlegt:

[highlight=c#]
public interface IDataProvider<T>
{
T GetDataObject();
}

public class Presenter
{
public Presenter(IView view, IDataProvider<ConcreteDataClass> dataProvider)
{
_view = view;
_dataProvider = dataProvider;

_dataClass = dataProvder.GetDataObject();
}
}
[/highlight]

Nun müsste man noch ein Objekt schaffen, welches das DatenObjekt hält und es bei Bedarf zurückgibt.

Eine andere Möglichkeit wäre:

[highlight=c#]
public interface IApplicationController
{
ConcreteDataClass GetDataObject(IView view);
}

public class Presenter
{
public Presenter(IView view, IApplicationController applicationController)
{
_view = view;
_applicationController = applicationController;

_view.OnInitialize += InitializeView;
}

private void InitializeView(Object sender, EventArgs e)
{
_dataObject = _applicationController.GetDataObject(_view);
}
}
[/highlight]

Im ApplicationController würd das dann so aussehen:

[highlight=c#]
public class ApplicationController:IApplicationController
{
private IDictionary<FormEditConcreteDataClass, IView> _dataMapping;

public void OpenView(ConcreteDataClass concreteDataClass)
{
FormEditConcreteDataClass form = (FormEditConcreteDataClass)ctx.GetObject("MyConcre teDataClassEditor");

_dataMapping.Add(form, concreteDataClass);

//Einfach an den Presenter weiterdelegieren
form.Initialize();
form.Show();
}

ConcreteDataClass GetDataObject(IView view)
{
if(_dataMapping.ContainsKey(view))
return _dataMapping[view];

throw new Exception("No mapping defined vor view: " + view.ToString());
}
}
[/highlight]

[das-d]

ich überlege gerade wenn meine View Kenntnis vom DAtenobjekt hat. (Auch eine Form vom MVP Pattern) dann könnte ich über Benutzernamen und Passwort ein Objekt erzeugen was beim Login Event an den Presenter weitergereicht wird als Referenz versteht sich. Der Presenter beauftragt meinen LogonService mit dem Login anhand der Daten dieses Objekts. Funktioniert das wird iwie die Logon Property meines Objektes auf True gesetzt --> wie genau weiß ich jetzt auch noch nicht (wie gesagt eine Setter Methode finde ich hier unangebracht) und gibt dieses an den Presenter zurück. Dieser oder der Service kümmert sich weiterhin um die Notifications an der View.
Meine View hat nun noch eine Property für mein Datenobjekt (nur getter versteht sich) und diese kann mein Application Controller auslesen.
Vielleicht ist dass dann das richtige Vorgehen?!

gruß Daniel

[fanderlf]

Naja... so wie ichs verstanden habe sollte der View über nichts vom Datenobjekt wissen. Das ist dann ein reines Passive View.
Aber ich habe diesen Ansatz auch schon implementiert. Ich habe mein DatenObjekt im View allerdings als Object deklariert und nicht als Objekt meine Datenklasse. Allerdings muss dann der Presenter das Datenobjekt zurückcasten. Ob das wirklich gut ist oder nicht weiss ich nicht
Ich hab eine Idee für Dein Login Problem:

[highlight=c#]
public class User
{
public String Username { get; set; }
public String Password { get; set; }


private bool _isLoggedIn;

public bool IsLoggedIn { get { return _isLoggedIn; } }

public bool Login()
{

if(_isLoggedIn)
return true;

LoginEventArgs e = new LoginEventArgs();
OnRequestLogin(e);

_isLoggedIn = e.LoginSuccessfull;

return _isLoggedIn;
}

public event EventHandler<LoginEventArgs> RequestLogin;

protected void OnRequestLogin(LoginEventArgs e)
{
if(RequestLogin != null)
RequestLogin(this, e);
}
}

public class LoginEventArgs:EvenArgs
{
public bool LoginSuccessfull { get; set; }

public LoginEventArgs()
{
LoginSuccessfull = false;
}
}
[/highlight]

Dein Presenter hängt sich jetzt auf das RequestLogin Event. Wenn Du Dich einloggen willst rufst Du die Funktion Login auf. Der Presenter reagiert und startet die Form und setzt LoginSuccessfull im Event. Dies wird innerhalb der Klasse gespeichert.

[das-d]

mir wiederstrebt es fast ein Objekt in der View als Objekt abzulegen aber überlegt hab ich mir genau das heute auch schon einmal ich muss mir da am Wochenende mal nochmal gedanken machen und dann denke ich komme ich schon auf einen vernünftigen Zweig.

Zum Datenobjekt in der view schau mal hier es gibt von Fowler zwei verschiedene Aussagen zum Pattern