Attualmente sto iniziando un nuovo progetto con un progetto di architettura a 4 livelli. I livelli sono impostati come segue.
+------------------+
+----------------+ Presentation |
| +------------------+
| |
| |
| +---------------v----------------+
| | |
| | Services (dll) |
| | |
| +-----+ +------+ +------+ +------+ |
| | | | Log <-->Print <--+Other | |
| | | +------+ +------+ +------+ |
| | | |
| | +--------------------------------+
| | |
| | |
| | +--------v---------+
| | +--------+ Business Logic |
| | | +------------------+
| | | |
+v---v---v+ |
| | +--------v---------+
| DTO <-------+ Data Access |
| | +------------------+
+---------+
Nel livello di servizio, ho riscontrato un problema di riferimento circolare come
-
Print Service
riferimentiLog service
quando è necessario registrare l'attività di stampa verso il basso. -
Log Service
riferimentiPrint Service
quando è necessario ottenere alcuni dettagli di stampa tramite un metodo inPrint Service
Tutti i servizi e gli altri livelli / livelli sono presenti come csproj, quindi verranno compilati come dll.
Mi piacerebbe sapere come posso sbarazzarmi di questo scenario? Dopo aver fatto qualche ricerca, la soluzione più possibile è creare un progetto di interfaccia per ogni servizio. C'è qualche altra soluzione migliore?
Se davvero adotto l'approccio ai progetti di interfaccia come soluzione, vuol dire che devo andare avanti con l'iniezione di dipendenza? La dipendenza dall'iniezione è potente, ma rende i codici più difficili da tracciare!
Infine, come Presentation Layer non può fare riferimento direttamente a BLL. Pertanto, alcune classi e modelli definiti in BLL non possono essere referenziati. È una buona idea archiviare tali classi e modelli nel progetto DTO in modo che possa essere utilizzato dai livelli con riferimento superiore indiretto? (Ovviamente, rinominerò il progetto DTO con un nome più significativo, ad es. BusinessObjects)
UPDATE 1
So che il mio esempio potrebbe non essere abbastanza buono. Fammi cambiare il requisito.
CourseService
e StudentService
questa volta. La dipendenza viene visualizzata come segue
+--------------------------------+
| |
| Services (DLL) |
| |
| +-------+ +-------+ |
| |Course <-------->Student| |
| +-------+ +-------+ |
| |
+--------------------------------+
-
CourseService
ha un metodoGetEligibleStudent(Course crs)
per elencareStudent[]
quelli che sono qualificati per registrare determinatiCourse
di base su alcune informazioni specifiche del corso e logica complessa inStudentService
. -
StudentService
ha bisogno di chiamarePrintGrade(Course crs, Student stu)
per recuperare determinati gradi di corso dello studente.
Sembra che questo esempio sia migliore. So che qualcuno potrebbe contestare che GetEligibleStudent(Course crs)
debba essere inserito in StudentService
o PrintGrade(Course crs, Student stu)
deve essere inserito in CourseService
. Tuttavia, la dipendenza circolare può esistere in qualsiasi momento durante lo sviluppo. Una soluzione appropriata dovrebbe essere presa, non solo nel mio esempio.