Es liegt nicht in der Verantwortung eines Controllers, es verstößt gegen SRP . Der Controller sollte überhaupt nicht von UoW wissen. Im Web wird normalerweise eine UOW pro Anfrage an den Server verwendet. In diesem Fall sollte UoW am Ende einer Anfrage angeordnet werden und irgendwo nach dem Beginn einer Anfrage gestartet werden (idealerweise sollte der Start einer UoW faul sein). Der beste Ort dafür ist Global.asax (oder Ihre HttpApplication-Klasse), die die Handler Application_EndRequest und Application_BeginRequest verwenden.
Dies kann leicht mit einem IOC-Framework (mein Liebling ist Windsor) erreicht werden, siehe diese Frage für Details zur Implementierung.
Der Controller. Dadurch wird der Kontext angezeigt, sodass Sie die Arbeitseinheit starten und beenden können. Bei einer nHibernate-Sitzung pro Anfrage müssen Sie beispielsweise wissen, wann die Anfrage gestartet und beendet wurde. Sie benötigen also den Kontext, um die Anfrage zu stellen.
Ich glaube an eine lose gekoppelte Architektur. Mein Controller weiß NICHTS über das Repository, den Kontext oder die Arbeitseinheit. Ich habe eine Service-Schicht erstellt (nicht sicher, dass das der richtige Begriff ist), die der Controller aufruft. Dieser Dienst arbeitet dann mit dem Repository (dll), um alle Daten zu erhalten.
Wie zihotki sagte, würden Sie die SRP verletzen, wenn Sie dem Controller diese Verantwortung übertragen. Dies ist ein datenmanipulationsorientiertes Muster und sollte daher für den Controller keine Rolle spielen ... das würde zwei Verstöße verursachen: einen für die SRP und einen weiteren für das SoC-Prinzip.
Was die Verantwortung betrifft, das muss von Ihrer Architektur definiert werden. Der StartRequest / EndRequest-Vorschlag scheint solide genug.
Tags und Links asp.net-mvc design-patterns architecture unit-of-work