Bonjour, Habr. Je veux parler de l'endroit où, dans la figure ci-dessus, placez le référentiel. Un peu plus sur le DIP, l'IoC et la structure du projet. Il existe une approche standard selon laquelle les interfaces IRepository doivent être perturbées dans la couche domaine vers DomainServices et la mise en œuvre dans Infrastructure. Ici, nous parlons de référentiels standard qui ne sont qu'une collection abstraite d'objets qui ne connaissent pas les transactions et UnitOfWork et ainsi de suite (par exemple, IList et sa version générique sont l'interface typique d'un référentiel abstrait). Personnellement, je ne suis pas d'accord avec lui, car les référentiels sont généralement envahis par un comportement spécifique à une application particulière, j'ai donc mis leurs interfaces à ApplicationServices. L'implémentation reste bien sûr dans la couche Infrastructure. Si vous êtes intéressé, alors bienvenue au chat.Souvent, beaucoup sont confus par la vieille photo de Robert Martin:
il a les mots dans l'articleLes entités encapsulent les règles commerciales à l'échelle de l'entreprise. Une entité peut être un objet avec des méthodes ou un ensemble de structures de données et de fonctions. Peu importe tant que les entités peuvent être utilisées par de nombreuses applications différentes dans l'entreprise.
Par conséquent, il s'avère qu'il attribue simplement DomainServices à la couche Entities. Eh bien, UseCases == ApplicationServices. Passerelles == UserPepository, EmailService, Logger. En savoir plus ici .- Serivice est n'importe quelle classe apatride. InfrastructureService est un gestionnaire anti-corruption qui vous isole du système de fichiers, de la bibliothèque pour travailler avec SMTP et, bien sûr, de ORM ou de la bibliothèque pour travailler avec la base de données, etc.
- Repository . . List Repository T[] ValueObject Entities. Repository InfrastructureService InfrastructureService Repository. : Logger, EmailSender.
- Repository InfrastructureService - EmailSender EmailService, FileService ( File.Open(… ) . .) .
Pour comprendre où placer les abstractions, nous devons penser à l'inversion des dépendances et à l'inversion du contrôle. Selon eux, notre ApplicationService peut utiliser l'infrastructure, je ne sais pas quelle est sa mise en œuvre de différentes manières:- Définissez l'interface qui implémentera l'infrastructure et interagira avec elle.
- Acceptez simplement les délégués comme Action et Func.
Via les interfaces: interface IRepository
{
int Get();
}
class ApplicationService
{
private readonly IRepository _repository;
public ApplicationService(IRepository repository)
{
_repository = repository;
}
public int GetInt() => _repository.Get();
}
Par l'intermédiaire des délégués: class ApplicationService
{
private readonly Func<int> _getIntFromDb;
public ApplicationService(Func<int> getIntFromDb)
{
_getIntFromDb = getIntFromDb;
}
public int GetInt() => _getIntFromDb();
}
Maintenant, comment structurer le code. Il y a deux cas à considérer:- Tout est divisé en dossiers.
- Tout est divisé en bibliothèques.
Les détails de la terminologie peuvent être trouvés ici .Dossiers dans la même application
Exemple de code SnakeGame
Par bibliothèques
Nous plaçons les interfaces InfrastructureServices (IRepository) dans la bibliothèque ApplicationServices et l'implémentation (Repository) dans la bibliothèque Infrastructure.
L'image finale de l' article est une personne ayant beaucoup plus d'expérience en développement que la mienne et qui pense également que IRepository devrait être placé dans la couche application vers ApplicationServices (les implémentations du référentiel elles-mêmes sont également dans l'infrastructure).
résultats
L'interface des services d'infrastructure (IRepository, IEmailSender) peut être placée dans la bibliothèque ApplicationServices.dll, et leur implémentation spécifique (Repository, EMailSender) dans la bibliothèque Infrastructure.dll.