perché esponendo il servizio al posto del repository nell'architettura della cipolla

4

Sto scavando su come strutturare i progetti e quindi inciampo in Onion Architecture. Per quanto riguarda il modo in cui lo capisco, è più su un'architettura basata su domini invece che su un tipo guidato da database.

Sto cercando alcuni progetti github per studiare e saperne di più sull'architettura, quindi ho trovato questo collegamento

Ho difficoltà a comprendere:

namespace Domain.Interfaces
{
    public interface IUserRepository
    {
        IEnumerable<User> GetUsers();
    }
}

namespace Services.Interfaces
{
    public interface IUserService
    {
        IEnumerable<User> GetUsers();
    }
}

namespace Services
{
    public class UserService : IUserService
    {
        private readonly IUserRepository _repository;

        public UserService(IUserRepository repository)
        {
            _repository = repository;
        }

        public IEnumerable<User> GetUsers()
        {
            return _repository.GetUsers();
        }
    }
}

Il modo in cui lo usa è tramite l'iniezione del costruttore.

private readonly IUserService _service;

public HomeController(IUserService service)
{
  _service = service;
}
  1. Esponi sempre un servizio come IUserService a un'app che lo consuma? Ma ho notato che IUserRepository ha gli stessi metodi per IUserService ?

  2. Se si dice che Infrastructure è preoccupante, significa o coinvolge il database? O non necessariamente? in caso contrario, quali sono gli esempi di problemi infrastrutturali?

P.S. Mentre sto imparando l'architettura della cipolla, sempre, se non sempre, almeno menziona il DDD. Quindi immagino che imparerò anche DDD:)

    
posta Boy Pasmo 19.04.2016 - 19:55
fonte

2 risposte

7

Do you always expose a service such as IUserService to an app that consumes it?

Sì, lo facciamo di solito. L'obiettivo è ridurre l'accoppiamento tra strati / livelli. Non legare i consumatori a implementazioni concrete ci consente di modificare l'implementazione del servizio senza compromettere i consumatori. Considerare le classi concrete come il dettaglio dell'implementazione e interfaccia il contratto per conformarsi.

D'altra parte, favorisce il testing dei consumatori perché le implementazioni dell'interfaccia possono essere derise, stubate o simulate. In altre parole, possiamo isolare i consumatori da dipendenze concrete.

But I noticed IUserRepository has the same methods to IUserService?

Sembra un difetto di design per me. È un sintomo di overengineering e ti sta dicendo: non hai bisogno di un servizio utenti. -

Allora cosa. Dovresti collegare i consumatori a IRepository ? Si perché no?. Fino a quando non avrai bisogno di una sorta di orchestrazione al momento di consumare il repository. L'orchestrazione probabilmente coinvolgerà IUserRepository e alcuni altri elementi che comporteranno complessivamente una sorta di transazione.

If you say Infrastructure concerns, does it mean or does it involve database?

I servizi di infrastruttura forniscono principalmente accesso a elementi esterni dell'architettura.

Alcuni esempi sono:

  • accesso al server di posta
  • accesso ai broker di messaggi
  • accesso alle code
  • accesso a archivi remoti (DB, file system, ecc.)
  • accesso ai dispositivi remoti

Queste preoccupazioni sono considerate traversali o ortogonali . Non sono strettamente correlati al dominio o alla logica aziendale. 1

Prendi una catena di montaggio come esempio. L'obiettivo della linea è assemblare le cose. Probabilmente ha bisogno di un approvvigionamento energetico. Qualunque cosa fornisca l'energia è considerata un servizio di infrastruttura. La natura dell'energia fornita non renderà la catena di montaggio in grado di cambiare il suo obiettivo.

Quindi sì, l'accesso ai database può essere considerato un problema di infrastruttura nelle architetture di cipolla. L'architettura onionica considera i database come elementi remoti con cui comunicare. Non sono più centric e dovrebbe essere possibile per noi modificare l'archivio dati senza dover cambiare il dominio. In teoria, il dominio è agnostico a questo dettaglio di implementazione. Tuttavia, è più facile da dire che da fare.

1: alcuni esempi sono sicurezza e registrazione

    
risposta data 19.04.2016 - 20:20
fonte
2

Onion architecture significa nascondere le dipendenze all'infrastruttura dietro un'interfaccia.

Tutti i componenti che utilizzano IUserService non hanno bisogno di sapere se il servizio è implementato utilizzando soap, rest, http o qualsiasi altra infrastruttura correlata.

L'implementazione UserService effettiva utilizza un'interfaccia repository IUserRepository come dettaglio di implementazione. UserService non ha bisogno di sapere quale infrastruttura viene utilizzata dall'user repository di implementazione (odbc, odedb, mssql-native, ....)

But I noticed IUserRepository has the same methods to IUserService?

Questa è una coincidenza.

    
risposta data 16.04.2018 - 19:36
fonte

Leggi altre domande sui tag