L'accoppiamento di progetto lento causa problemi nella soluzione .NET Core

Naviga le tue risposte
1

abbiamo avviato un nuovo progetto in cui il back-end consiste di diversi livelli (ciascuno in un progetto diverso).

Per semplificare ne definirò alcuni:

  1. Project.Data - livello di dati con accesso a db
  2. Project.Repository - repos
  3. Project.Repository.Interfaces - solo interfacce di repository
  4. Project.WebApi - API

Il nostro team leader ha proposto che dovremmo bloccare l'accesso alle risorse tra i progetti a livello di riferimento. Ora l'unica cosa che l'API farà riferimento in questo esempio è Project.Repository.Interfaces. Lì iniettiamo interfacce usando Dependency Injection. Come ho detto, questa è una versione semplice che non include Servizi e Dtos.

L'idea alla base di questo è che WebAPI dovrebbe utilizzare solo DI per accedere alle risorse. Anche WebAPI dovrebbe avere accesso a DTO non direttamente alle entità del database. Tutto questo è grandioso, ma naturalmente ci sono alcuni problemi che sono stati riscontrati e non sono sicuro di come risolverli:

a) I pacchetti Nuget installati in Project.Repository non vengono copiati in WebAPI (eccezione di runtime relativa alla dll mancante)

b) l'uso di .NET Core CLI e dotnet watch eseguiti per avviare un progetto localmente non tengono traccia delle modifiche nei progetti figli poiché non vengono referenziati direttamente.

Vedo la visione dietro questa idea di accoppiamento sciolto, ma questo è davvero ingombrante. È un compromesso con cui devi convivere in tale situazione o c'è una soluzione per questo?

Saluti

    
posta Mateusz Migała 13.12.2018 - 15:02
fonte

2 risposte

1

Sì, è una seccatura non costruire tutto ciò di cui hai bisogno, dove ne hai bisogno, nel momento in cui ti rendi conto di averne bisogno. Il codice procedurale è molto più facile da scrivere. È sempre stato Sarà sempre. Il problema principale di uno sviluppatore maturo non è la velocità di scrittura. È velocità di lettura.

Rendere esplicite le tue dipendenze mi aiuta a leggere il tuo codice. Fallo e io posso usare il tuo codice quando è il momento di apportare modifiche. Preferirei non doverlo bruciare a terra. Pensare alla prossima povera scimmia del codice che avrà a che fare con il mio codice è come ottenerlo.

Hai detto che lavorare in questo modo rompe alcuni dei tuoi strumenti. Questo è vero. Il mio più grande problema è fare clic su qualcosa e ottenere l'astrazione non l'implementazione. Tutto quello che posso dire è che abbiamo bisogno di strumenti migliori.

Il costo del lavoro dinamico è l'analisi statica. Il costo del lavoro statico sta vivendo con il codice statico. Scegli il tuo veleno.

    
risposta data 13.12.2018 - 16:01
fonte
0

Il tuo problema è che ti manca un punto di ingresso nella tua architettura.

Puoi rendere tutto il progetto libero e probabilmente dovrebbe, ma avrai sempre bisogno di un progetto che incollerà tutti gli altri insieme e eseguirà l'applicazione.

Per l'applicazione di solito è un progetto con il metodo Main .
Il modo in cui ASP.NET Core funziona il progetto del punto di ingresso dovrebbe essere un progetto WebAPI.

Quindi cercare di sbarazzarsi di altre dipendenze in WebAPI non è l'approccio corretto come già notato.

    
risposta data 14.12.2018 - 00:12
fonte

Leggi altre domande sui tag

Parametri di paging - interfaccia del repository di dominio Qual è la migliore unità di misura per disegnare con script utente?