2016-04-09 4 views
0

Im Onion-Framework kann die äußere Schicht auf alle inneren Schichten zugreifen. Wenn ich damit fortfahre, kann meine äußere Schicht (die in der MVC die UI-Schicht/den Controller ist) direkt auf Anwendungs-/Geschäftsdienste und Repositories zugreifen. Jetzt kann mein Controller ein Domänenmodell erstellen und im Datenspeicher mithilfe des Repositorys persistent machen. Und umgehen Sie damit die Validierung und andere Geschäftsregeln, die in der Business-Schicht geschrieben sind. Ich glaube, ich vermisse etwas. Bitte helfen Sie.Onion Framework: Sollen UI/Controller direkten Zugriff auf das Repository haben

public SpeakerController(IConferenceRepository conferenceRepository, 
         IUserSession userSession, IClock clock) 
    : base(userSession) { 
    _conferenceRepository = conferenceRepository; 
    _clock = clock; 
    _userSession = userSession; } 

von http://jeffreypalermo.com/blog/the-onion-architecture-part-2/

Antwort

1

sage ich "Nein", obwohl Palermo sich sonst in twitter Gespräche angezeigt hat. Ich sage, dass jede Schicht mit der nächsten inneren Schicht sprechen und sie nicht umgehen darf. Die Ausnahme, die ich zu dieser Regel mache, ist, wenn die in Frage stehende Funktionalität grundsätzlich nur CRUD für Referenzdaten ist. Ich sehe keinen Grund, die zusätzliche Komplexität für diese Art von Daten einzuführen.

Eine andere Alternative besteht darin, dass Ihre Repository-Implementierung die Validierung von Geschäftsregeln erzwingt. Da die Implementierung auf der äußersten Schicht der Zwiebel erfolgt, sollte dies ziemlich einfach sein.

Ich habe gefunden Alistair Cockburn Hexagonal Architecture Beleuchtung und einfacher, dass Zwiebel-Architektur. Grundsätzlich gibt es "in meiner Anwendung" und "außerhalb meiner Anwendung". Immer wenn Sie diese Grenze überschreiten müssen, benötigen Sie einen Adapter, um Ihre Anwendung vor den Implementierungsdetails zu schützen.

+0

Wenn ich Sie richtig verstanden habe, meinen Sie, dass es keine Wrapper-/Pass-through-Methoden in der Business-Klasse für den CRUD-Betrieb geben muss. Es ist in Ordnung, Repository-Methoden in der Benutzeroberfläche zu verwenden. Für mich ist die Validierung von Geschäftsregeln im Repository keine gute Idee. Dies wird den Zweck des Business-Layer besiegen. – Pragmatic

+0

Es gibt zwei verschiedene Probleme: Referenzdaten und Validierung. Ich werde sie in separaten Kommentaren behandeln. Re: Referenzdaten Sagen wir, ich habe eine Tabelle namens StateOrProvince. Es kann sein, dass ich für diese Daten keine Geschäftsregeln außer den erforderlichen Feldern und der Eindeutigkeit habe. Diese Regeln können von der Datenbank erzwungen werden. Für diese Daten gibt es keine anderen Operationen als CRUD. Das Entwickeln eines Domänenmodells für diese Art von Daten ist möglicherweise übertrieben. Normalerweise verbinde ich in diesem Fall meine Ansicht direkt mit meinem ORM. –

+0

Betreff: Validierung Sie schreiben Ihre Validierungslogik in Ihre Domänenebene. Sie sollten Abstraktionen haben, die Ihre in Ihrer Domänenebene definierte Persistenzschicht darstellen, die Ihre Domänenobjekte verwenden können. Es gibt keinen Grund, warum Sie die Validierungslogik Ihres Domänenobjekts bei der Implementierung Ihrer Persistenzschicht nicht aufrufen können. Wenn Sie sich das OA-Diagramm genauer ansehen, befindet sich die Persistenz tatsächlich auf einer der äußersten Sprossen des Diagramms. Dies bedeutet, dass Sie den vollständigen Kontext der Domäne in Ihrer Persistenzschicht erhalten. Du kannst es genauso gut benutzen. –