Meiner Meinung nach, was Sie erreichen wollen, ist eine gute Möglichkeit, das Projekt zu gestalten. Ich mache das auch; nur ein kleiner Unterschied, den ich unten erklären werde. Wenn Sie nicht auf DAL in API verweisen, stellen Sie sicher, dass jeder Aufruf von DAL nur über BLL erfolgt. Dies ist notwendig, weil ich meine gesamte Datenverarbeitungslogik an einem Ort ablegen möchte. Wenn es verteilt wird, ist es schwierig, Probleme zu lokalisieren.
Ich habe vier Projekte:
- Utils (Ihre "blabla" Sachen geht hier) [Referenzen nichts]
- DAL (Datenbank Sachen geht hier) [Referenzen Utils]
- BLL (Ihr Logik Sachen geht hier) [Referenzen DAL und Utils bei Bedarf]
- Api (API Sachen geht hier) [Referenzen BLL und Utils bei Bedarf]
Dies ist eine Einweg-Referenzkette. DAL => BLL => API. Referenzen in umgekehrter Reihenfolge sollten nicht existieren. Utils sollte gemeinsame Sachen sein, in denen gängige Dinge wie Entity-Deklarationen, Exceptions, Enums gehen sollten.
Hinweis: Obwohl Sie die DAL in der API nicht referenzieren, müssen Sie sie bereitstellen.
Um die Verwendung von Utils in API zu vermeiden, müssen Sie möglicherweise eine weitere Schicht von DTOs hinzufügen und sie mit Entitäten abbilden. Siehe meine anderen question auf demselben.
müssen Sie auf die DAL Ihres Hauptprojekts verweisen, wenn die BLL davon abhängt. Sonst wie findet der BLL die Funktionen die er anrufen soll? Der kompilierte Code der DAL würde fehlen. So funktioniert es, es gibt keine Bedenken. – ADyson
Aber du BLL sollte irgendwo DAL verwenden? – McNets
@ADyson mein BLL-Projekt verwendet die DAL, aber warum sollte ich einen Verweis auf DAL in der API hinzufügen, wenn ich BLL darin verweise? –