2012-04-15 5 views
0

Ich bin eine Website in MVC3 Schreiben, mit Entity (zu Postgres verknüpft, aber nicht sicher, dass ein Teil relevant ist.Filtern von Daten durch den Zugriff der Benutzerrechte

Ein Benutzer Teil einer Reihe von „Ligen“ ist, und erstellt ein "Ereignis" gegen eine dieser Ligen.

Es wird andere Benutzer geben, die Zugriff auf diese Liga haben, und wenn sie eine Liste der Ereignisse anzeigen, brauche ich die Liste, um nur diese "Ereignisse" anzuzeigen das sind Teil von "Ligen" sie haben Zugang zu.

Jetzt gibt es zahlreiche Möglichkeiten, dass dies erreicht werden könnte, aber ich bin auf der Suche nach den elegantesten und weithin akzeptiert sei "der richtige Weg".

Derzeit wird die User -> Liga-Beziehung an der gleichen Stelle wie der Rest der Daten gehalten, daher kann ich einfach nach den Ligen filtern, ohne ein Problem. Mein Problem ist, dass ich nicht sicher bin, ob ich auf den HttpContext zugreifen sollte oder nicht, um die UserId innerhalb der Repository-Ebene für das Filtern zu erhalten.

Wenn ich das oben Gesagte nicht mache, erwäge ich, die RoleMembership-Funktionalität zu verwenden und Ligen, Rollen zu erstellen, und dann gibt es eingebaute Funktionen, um das zu tun.

Die Frage ist, was ist die beste Praxis für das Filtern von Ergebnisdaten durch Benutzerzugriff in MVC3/Entity?

Blogs/Tutorial Links werden bevorzugt, aber vollständige Antworten können auch akzeptiert werden ...

Antwort

1

ich auf jeden Fall glaube nicht das Repository sollte das Httpcontext-Objekt wird aufgerufen wird. Ich würde empfehlen, das Abhängigkeitsinjektionsmuster für diese Anwendung zu befolgen. In diesem Szenario gibt es drei Schnittstellen - eine ist die Datenzugriffsschnittstelle (das Repository); ein anderer ist der Anbieter von gefilterten Daten für Ihre Ansicht (das Ansichtsmodell); und eine dritte ist der Anbieter von Rolleninformationen (der Rollenanbieter).

So ist das Repository eigenständig; Der Rollenanbieter hat eine Abhängigkeit (ich entnehme es Ihrer Frage) auf HttpContext; und das Ansichtsmodell hängt sowohl vom Repository als auch vom Rollenanbieter ab. Ich würde betonen, dass Sie einen Abhängigkeitswrapping aller HttpContext-Methoden schreiben, die Sie verwenden möchten, um das Testen zu erleichtern.

Es gibt eine recht umfangreiche Tutorial über Abhängigkeitsinjektion und MVC, auf MSDN: http://msdn.microsoft.com/en-us/gg618491

Zur Veranschaulichung:

public interface ILeagueRepository 
{ 
    IEnumerable<League> All; 
} 

public interface ILeaguesProvider 
{ 
    IEnumerable<League> GetUserLeagues(string Username); 
} 

public class LeaguesProvider : ILeaguesProvider 
{ 
    public LeaguesProvider(ILeagueRepository repository) 
    { 
     // ... 
    } 
    public IEnumerable<League> GetUserLeages(string Username) 
    { 
     return _repository.All.Where(league=>league.User == Username); 
    } 
} 

public ActionResult LeaguesController 
{ 
    public LeaguesController(ILeaguesProvider providerDependency, IRoleProvider roleDependency) 
    { 
     IEnumerable<League> leagues = providerDependency.GetUserLeagues(roleDependency.GetCurrentUser()); 
    } 
} 
+0

ich Ninject für DI bin mit, so dass kein Problem. Ich bin mir immer noch nicht sicher, wo der Filter angewendet wird ... kannst du das weiter ausführen? – Martin

+0

@Martin Ich fügte eine grobe Skizze von dem hinzu, was ich meinte, hoffentlich hilft das. Der Schlüsselpunkt, den ich versuche, besteht darin, die Rollenabhängigkeit nicht in das Repository zu mischen und niemals direkt gegen HttpContext, sondern gegen eine von Ihnen definierte Abhängigkeit zu codieren. – McGarnagle

Verwandte Themen