Was ist die empfohlene Ordnerstruktur von Katalogen im Projekt mit IoC

Question

Ich habe einige Artikel gelesen und viele Vorträge/Tutorials zu YT über DI und IoC gesehen, aber ich habe kein empfohlenes Layout von Katalogen in VS-Lösung gefunden.

Ich spreche über das Projekt (ein Spiel, zum Beispiel), wo Sie einige Klassen/Schnittstellen, Logger, Datenbankanbieter, WCF-Dienste, wpf Präsentationsschicht (das ist eigentlich anderes Projekt) ...

Ist Gibt es irgendein Musterprojekt, das zeigt, wie ich mein Projekt organisieren soll, damit ein erfahrener Programmierer keine Zeit damit verschwendet, herauszufinden, was vor sich geht? Da wir von "selbstkommentarem Code" sprechen, spreche ich von "selbst kommentierter Projektstruktur".

Zum Beispiel, sollte ich alle Schnittstellen in "Schnittstellen" Katalog setzen? Oder sollte ich (im Fall von Logger) den "Logger" -Katalog erstellen und dort eine Schnittstelle, Klassen, Klassen mit Erweiterungsmethoden (alle auf die Protokollierung ausgerichtet) setzen. Der Code konzentriert sich auf das Board, im "Board" -Katalog. Getrennter Katalog für "Feld" usw. ETC

Gerade jetzt sieht die Struktur so aus. Ich bin mir nicht sicher "Business" dort und Logger. Ich habe Schnittstelle in anderem Katalog als andere Logger-Klassen. Soll ich den Log4Net-Provider anrufen? oder Adapter? oder Dekorateur? Es ist nur eine Logger-Klasse, die ILogger Schnittstelle implementiert. Hier ist der Bildschirm: link

Hier ist der Beispielcode (es gibt keine IoC noch nicht, aber jeder wird bemerken, dass es drei Schnittstellen werden dort abgebildet Sehr einfach.):

public class Game 
{ 
    public IBoard Board { get; set; } 

    public Game(IBoard board) 
    { 
     Board = board; 
    } 
} 

public interface IBoard {} 

public class Board : IBoard 
{ 
    public IField[,] Fields { get; set; } 
    public Board(IField field, int boardWidth, int boardHeight) 
    { 
     Fields = new IField[boardHeight, boardWidth]; 
     Fields.Initialize(); 
    } 
} 

public interface IField {} 

public class Field : IField {} 

public interface ILogger 
{ 
    void Log(LogEntry entry); 
} 

Answer 1

Was ich in der Regel tun ist dass ich einen MyApplication.Core (Klassenbibliothek) Layer habe, der alle Anwendungsschnittstellen mit so wenig (read: none) Drittanbieterabhängigkeiten enthält, z ILogger, ICommand oder IQuery<TResult>.

Als nächstes habe ich eine MyApplication.Domain (Klassenbibliothek) Schicht, die das gesamte Anwendungsgebiet spezifische Kenntnisse enthält - das ist die Business-Schicht. Dies sind Implementierungen der Kernschnittstellen ICommand, IQuery<TResult>. Diese Implementierungen haben dann eine Abhängigkeit von z.B. ILogger. Nie konkrete Implementierungen.

Dann habe ich die MyApplication.Infrastructure (Klassenbibliothek), wo alle Service-Schnittstellen von MyApplication.Core implementiert ist, z. ILogger. Hier können Sie Abhängigkeiten von Bibliotheken von Drittanbietern wie Log4Net haben.

Dann zuletzt habe ich die Präsentationsschicht, die in meinem Fall in der Regel eine MVC-Anwendungen ist, so würde ich dies nennen. Alle Controller haben nur Abhängigkeiten von den Schnittstellen. Nie konkrete Implementierungen. Diese Schicht ist auch verantwortlich für das Bootstrapping aller Schnittstellen zu den konkreten Implementierungen unter Verwendung einer Composition Root.

TL; DR:

• MyApplication.Core (Application Interface Layer)
• MyApplication.Domain (Business Logic)
• MyApplication.Infrastructure (Implementationen von Application Interface Layer)
• MyApplication. Netz.Mvc (Darstellung und Zusammensetzung der Start Layer)