Wohin sollten diese Klassen/Methoden gehen?

Question

Ich habe eine solche Struktur

Webui -Projekt - Controller, Rahmenprojekte -Repositories, Service Layer und Domain

Jetzt habe ich 3 Methoden/Klassen

1. Open ID/Open Auth

Zuerst dachte ich, ich würde meine gesamte Logik in eine Serviceschicht in mein Framework -Projekt einfügen (Vorbereitung der Anfrage, die Überprüfung der Antwort usw. würde in dieser Ebene sein).

Jetzt verwende ich die DotNetOpenAuth -Bibliothek und weil ich die ASACTIONRESULT -Methode in meinem Controller verwenden muss (ich kehre "Ausgangswebwirkse" aus meiner Serviceschicht zurück, da ich nichts MVC in meinen Serviceschichten möchte)

Es brachte mich zum Nachdenken, als ich mich entschied, nichts MVC in meiner Serviceschicht zu haben. Wie ich lese, sollte Ihre Serviceschicht, die Ihre Geschäftslogik enthält, keine Abhängigkeiten wie MVC -Referenzen haben, da Sie bei einer Windows -Telefonanwendung keine MVC -Dinge verwenden sollten.

Ihre Geschäftsschicht sollte eine Art Plug -and -Play in jede Anwendung sein.

Jetzt bin ich mir also nicht sicher, ob ich das, was ich für OpenID in meinem Modelsordner geschrieben habe, in meinem MVC -Projekt nur aus den oben genannten Gründen in meinen Models -Ordner verschieben sollte. Wenn ich zu einer Windows -Telefonanwendung oder -anwendung gehe, werde ich DotNEAuth nicht verwenden, da ich nicht der Meinung bin, dass sie in solchen Anwendungen unterstützt werden.

1. Mein zweiter ist mit Formularen Authentifizierung. Wieder so ziemlich die gleichen Gründe wie oben. Sollte dies auch in meinem Modelsordner als lokaler Dienst/Repo -Ebene (dh in derselben Projektdatei) gehen.

2. Ich verwende Nhibernate, fließend Nhiberat und Ninjekt. Meine Repos sind alle in meinem Framework -Projekt. Also habe ich natürlich alle Referenzen dort. Aber da ich Ninject für IOC verwende, habe ich auch alle Referenzen in meinem Webui -Projekt.

Ich habe keine Ahnung, ob dieser geändert werden könnte, um diese Referenzen von meinem Webui zu entfernen. Ich denke nein, weil ich mein IOC in meinem Webui nicht haben kann, wo ich denke, dass es gehen sollte.

Answer 1

Als allgemeine Faustregel sollten Sie keinen Code gegen Anforderungen schreiben, die nicht vorhanden sind (Portion der App auf ein Windows -Telefon).

Normalerweise würden Sie dies in Ihrer Serviceschicht abstrahieren, aber die OAuth- oder Facebook -Integration hat ein Problem, weil sie auf HTTP angewiesen und die Authentifizierungs -Site besuchen kann.

Das Problem, auf das Sie stoßen, weil "Alle Abstraktionen sind undicht"Ist Ihre Serviceschicht irgendwie durch den OpenAuth -Registrierungsprozess beschädigt, unabhängig davon, wo Sie sie platzieren /Modell/MVC/ViewModel/Controller -Klassen werden alle wissen, was OpenAuth für seine Natur ist.

Das Gute ist, dass diese browserbasierten Authentifizierungsstrategien in Windows -Form, WPF oder Silverlight -Anwendung leben können. Sie öffnen einfach einen Browser in der Anwendung, anstatt nativ mit MVC umzuleiten.

Ich würde also empfehlen, Ihren DotNetopen -Auth -Registrierungscode in Ihre Serviceschicht zu platzieren und tatsächlich abstrahiert, wie der Umleitungs- und Rückrufprozess stattfindet.

Etwas wie:

public interface IOpenAuthRedirect
{
      public void Redirect( url )
      public void ParseCallback( url )
}


public class MVCOpenAuthRedirect
{
     public void Redirect(url)
     {
        HttpContext.Current.Response.Redirect(url);
     }
}

public class SilverlightOpenAuthRedirect
{
    public void RedirectUrl( url )
    {
        SomeBrowserControl.IForgetTheCallToRedirect( url );
    }   

}

Jetzt sind die verschiedenen Implementierungsdetails flexibel und Sie können neben MVC problemlos auf eine andere Plattform wechseln.