Qual è la struttura di cartelle consigliata dei cataloghi nel progetto usando IoC

Question

Ho letto alcuni articoli e ho guardato molte lezioni/esercitazioni su YT su DI e IoC, ma non ho trovato alcun layout consigliato di cataloghi nella soluzione VS.

Sto parlando del progetto (un gioco per esempio) in cui si dispone di alcune classi/interfacce, logger, provider di database, servizi WCF, WPF livello di presentazione (che è in realtà diverse del progetto) ...

Is c'è qualche progetto di pattern, che mostra come dovrei organizzare il mio progetto, quindi il prossimo programmatore esperto non perderà tempo a capire cosa sta succedendo? Come stiamo parlando di "self commented code", sto parlando di "self commented project structure".

Ad esempio, dovrei inserire tutte le interfacce nel catalogo "Interfacce"? O dovrei (nel caso del logger) creare il catalogo "Logger" e mettere lì l'interfaccia, le classi, la classe con i metodi di estensione (tutti concentrati sulla registrazione). Codice focalizzato su Board, nel catalogo "Board". Catalogo separato per "Campo" ecc. Ecc.

In questo momento la struttura sembra così. Non sono sicuro di "Business" lì e Logger. Ho un'interfaccia in un catalogo diverso da altre classi di logger. Devo chiamare il fornitore di Log4Net? o adattatore? o decoratore? È solo una classe di logger che implementa l'interfaccia ILogger. Ecco la schermata: link

Ecco il codice di esempio (non c'è CIO ancora, ma tutti si accorge ci saranno 3 interfacce non mappati molto semplice.):

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

Cosa faccio di solito è che ho un livello MyApplication.Core (libreria di classi), che contiene tutte le interfacce delle applicazioni con le dipendenze di terze parti (leggere: nessuna), ad esempio ILogger, ICommand o IQuery<TResult>.

Successivamente ho un livello MyApplication.Domain (libreria di classi) che contiene tutte le conoscenze specifiche del dominio dell'applicazione: questo è il livello aziendale. Questa è l'implementazione delle interfacce principali ICommand, IQuery<TResult>. Queste implementazioni hanno quindi una dipendenza da es. ILogger. Mai implementazioni concrete

Quindi ho la MyApplication.Infrastructure (libreria di classi) che è dove sono implementate tutte le interfacce di servizio da MyApplication.Core, ad es. ILogger. Qui puoi avere dipendenze da librerie di terze parti come Log4Net.

Quindi, ultimo ho il livello di presentazione, che nel mio caso è di solito un'applicazione MVC, quindi chiamerei questo MyApplication.Web.Mvc. Tutti i controller hanno solo dipendenze sulle interfacce. Mai implementazioni concrete Questo livello è anche responsabile del bootstrap di tutte le interfacce con le implementazioni concrete utilizzando uno Composition Root.

TL; DR:

• MyApplication.Core (Application Interface Layer)
• MyApplication.Domain (Business Logic)
• MyApplication.Infrastructure (Implementazioni di Application Interface Layer)
• MyApplication. Web.Mvc (Presentation and Composition Root Layer)