Hallo Habr. Ich möchte darüber sprechen, wo in der obigen Abbildung das Repository abgelegt wird. Ein bisschen mehr über DIP, IoC und Projektstruktur. Es gibt einen Standardansatz, nach dem die IRepository-Schnittstellen in der Domänenschicht zu DomainServices und der Implementierung in Infrastructure gestört werden müssen. Hier geht es um Standard-Repositorys, bei denen es sich lediglich um eine abstrakte Sammlung von Objekten handelt, die nichts über Transaktionen und UnitOfWork usw. wissen (z. B. sind IList und seine generische Version die typische Schnittstelle eines abstrakten Repositorys). Ich persönlich bin mit ihm nicht einverstanden, da Repositorys normalerweise mit einem für eine bestimmte Anwendung spezifischen Verhalten überwachsen sind. Deshalb habe ich ihre Schnittstellen zu ApplicationServices gestellt. Die Implementierung bleibt natürlich in der Infrastrukturschicht. Wenn Sie interessiert sind, dann willkommen bei cat.Oft verwirrt das alte Bild von Robert Martin viele:
Er hat die Worte im ArtikelEntitäten kapseln unternehmensweite Geschäftsregeln. Eine Entität kann ein Objekt mit Methoden oder eine Reihe von Datenstrukturen und -funktionen sein. Es spielt keine Rolle, solange die Entitäten von vielen verschiedenen Anwendungen im Unternehmen verwendet werden können.
Daher stellt sich heraus, dass DomainServices einfach der Entitätsschicht zugewiesen werden. Nun, UseCases == ApplicationServices. Gateways == UserPepository, EmailService, Logger. Lesen Sie hier mehr .- Service ist jede staatenlose Klasse. InfrastructureService ist ein Anti-Korruptions-Laer, der Sie vom Dateisystem, der Bibliothek für die Arbeit mit SMTP und natürlich von ORM oder der Bibliothek für die Arbeit mit der Datenbank usw. isoliert.
- Repository . . List Repository T[] ValueObject Entities. Repository InfrastructureService InfrastructureService Repository. : Logger, EmailSender.
- Repository InfrastructureService - EmailSender EmailService, FileService ( File.Open(… ) . .) .
Um zu verstehen, wo Abstraktionen platziert werden sollen, müssen wir über Abhängigkeitsinversion und Inversion der Kontrolle nachdenken. Demnach kann unser ApplicationService die Infrastruktur verwenden. Ich weiß nicht, wie sie implementiert wird, z. B.:- Definieren Sie die Schnittstelle, die die Infrastruktur implementiert, und interagieren Sie mit ihr.
- Akzeptiere einfach Delegierte wie Action und Func.
Über Schnittstellen: interface IRepository
{
int Get();
}
class ApplicationService
{
private readonly IRepository _repository;
public ApplicationService(IRepository repository)
{
_repository = repository;
}
public int GetInt() => _repository.Get();
}
Durch Delegierte: class ApplicationService
{
private readonly Func<int> _getIntFromDb;
public ApplicationService(Func<int> getIntFromDb)
{
_getIntFromDb = getIntFromDb;
}
public int GetInt() => _getIntFromDb();
}
Nun zur Strukturierung des Codes. Es sind zwei Fälle zu berücksichtigen:- Alles ist in Ordner unterteilt.
- Alles ist in Bibliotheken unterteilt.
Details zur Terminologie finden Sie hier .Ordner innerhalb derselben Anwendung
SnakeGame-Codebeispiel
Von Bibliotheken
Wir fügen die InfrastructureServices-Schnittstellen (IRepository) in die ApplicationServices-Bibliothek und die Implementierung (Repository) in die Infrastructure-Bibliothek ein.
Das letzte Bild aus einem Artikel einer Person mit viel mehr Entwicklungserfahrung als meiner, die auch der Meinung ist, dass IRepository in der Anwendungsschicht für ApplicationServices platziert werden sollte (die Repository-Implementierungen selbst verfügen ebenfalls über Infrastruktur).
Ergebnisse
Die Infrastrukturdienstschnittstelle (IRepository, IEmailSender) kann in der Bibliothek ApplicationServices.dll und ihre spezifische Implementierung (Repository, EMailSender) in der Bibliothek Infrastructure.dll abgelegt werden.