c # Che problema si verifica quando uso la classe statica per il database di accesso?

1

Molti siti che ho letto sul metodo statico hanno detto che per favore non dovrebbero usare il metodo statico per l'accesso al database e dovrebbero usare dependency injection per iniettare altri servizi e usare quel servizio per scrivere altra logica.Ma ci sono problemi  capita quando iniettare AService in BService e iniettare AService in CService molti mesi passano la logica di business è far crescere ho bisogno di iniettare BService in CService, Fa problema causa che AService già iniettare in due punti non può farlo. Provo qualcosa di simile per risolvere quella soluzione.

 public class InterlocutorFacade : GenericEFRepository<MsSql1DbContext, GenericUser>, IInterlocutorFacade
 {
    public InterlocutorFacade(MsSql1DbContext _msGenericDb) : base(_msGenericDb)
    {

    }

    public async Task AddC()
    {
        await UserService.CreateLogs(_msGenericDb.Set<Logs>());
        await _msGenericDb.SaveChangesAsync();
    }


    public async Task GetC()
    {
        var result = await UserService.GetFirstLogs(_msGenericDb.Set<Logs>());
    }
 }

e questo è il servizio che uso

public static class UserService
{ 
    internal static async Task<Logs> GetFirstLogs(DbSet<Logs> dbSet)
    {
        var result = await dbSet.FirstOrDefaultAsync();
        return result;
    }

    internal static async Task CreateLogs(DbSet<Logs> dbSet)
    {
        var result = await dbSet.AddAsync(new Logs() { });
    }

}

Ma non sono sicuro di quale problema accadrà se lo faccio, qualcuno mi può mostrare un problema (prestazioni, conflitto di dati) che accadrà quando lo uso?

    
posta uopeydel 28.11.2018 - 03:40
fonte

1 risposta

3

Il problema con l'utilizzo di una statica per l'iniezione di una dipendenza è che non si è in grado di cambiare l'implementazione. Questo è principalmente fatto nei tuoi test unitari

es

public class Service
{
    public Service() {}
    public AddData(Data data)
    {
        MyStaticDBClass.Add(data);
    }
}

Nell'applicazione funziona bene, ma nel test dell'unità verrà scritto sul database. Che non vuoi che faccia.

Rispetto a:

public class Service
{
    private readonly IDataLayer dl;
    public Service(IDataLayer dl) { this.dl = dl;}
    public AddData(Data data)
    {
        dl.Add(data);
    }
}

Ora nell'applicazione posso passare nell'oggetto reale del livello dati e nel mio test passo in una versione derisoria.

Secondo problema. La dipendenza ciclica sta fondamentalmente dicendo che non puoi compilare dll A perché dipende da dll B e non puoi compilare dll B perché dipende da A.

Per risolverlo dovrai separare le interfacce dalle implementazioni. Inseriscili in diversi progetti, ad es.

IAService //no references
    IAService.cs //interface for AService

IBService //no references
    IBService.cs //interface for BService

AService // references IAService and IBService
    Aservice.cs //implementation of IAService


BService // references IAService and IBService
    BService.cs //implementation of IBService

Ora posso compilare il progetto IAService prima come il riferimento IBService è solo nel progetto di implementazione reale

    
risposta data 28.11.2018 - 11:29
fonte