Eine Webanwendung, mit der Psychotherapeuten, die sich auf ihr Fachgebiet spezialisiert haben, auf dieser Plattform Fragen beantworten können, die ihnen gestellt werden.
Ich habe verwendet:
Architektonisches Gebäude
Das Projekt besteht aus zwei Schichten. Persistenzschicht, die mit der Datenbank verknüpft ist, und Kernschicht, die nicht mit der Datenbank verknüpft ist
Controller => Kern <= Persistenz
Wir können über ein Abhängigkeitsdiagramm wie dieses sprechen. Die Kernschicht enthält Schnittstellenklassen. Persistenz enthält die Klassen, in denen ich diese Schnittstellen definiere. Auf der Controller-Seite habe ich die UnitOfWork -Klasse verwendet, um die Controller-DBContext- Abhängigkeit zu reduzieren. Obwohl es sich bei dem Controller um eine High-Level -Schicht handelte, war er eng mit UnitOfWork, einer Low-Level -Schicht, verbunden. Ich habe dafür die Klasse IUnitOfWork verwendet. IUnitOfWork definiert eine vollständig abstrakte Klasse, die IRepositorys enthält. Dann habe ich die UnitOfWork -Klasse von der IUnitOfWork -Klasse abhängig gemacht. Ebenso habe ich eine Abhängigkeit zwischen der Controller- Ebene und IUnitOfWork erstellt.
Controller => IUnitOfWork <= UnitOfWork
Jetzt ist die übergeordnete Controller -Ebene von einer abstrakten Klasse abhängig. Ebenso ist Abstrack in UnitOfWork, einer Low-Level- und detaillierten Klasse, von einer Klasse abhängig geworden. Eigentlich habe ich die Kernschicht völlig unabhängig gemacht. Die Testbarkeit der Anwendung ist gestiegen. Darüber hinaus verfügt der Core Layer über eine vom ORM Framework unabhängige Struktur. Die in UnitOfWork vorzunehmende Änderung hat keine Auswirkungen auf die IUnitOfWork-Ebene.
Andererseits bestand in der Anwendung die DbContext- Abhängigkeit immer noch in der UnitOfWork-Schicht fort. Dies verursachte indirekt das Problem der engen Kopplung von Controller und DbContext . Ich habe ein Dependency Injection Framework verwendet, um dieses Problem zu lösen. (Ninject 3.2.1.0)