Servizi di dominio come facciate

Question

Servizi di dominio come facciate

#1 da (7 voti)
#2 da (2 voti)

8

Ho letto .NET Domain-Driven Design con C #: Problem - Design - Solution e ho notato che il autore ha creato un servizio di dominio per ogni radice aggregata.

Tuttavia, i servizi di dominio erano solo facciate per il repository corrispondente. Ad esempio questo è un esempio di codice dall'applicazione del suo libro

public static class CompanyService
{
    private static ICompanyRepository repository;
    private static IUnitOfWork unitOfWork;

    static CompanyService()
    {
        CompanyService.unitOfWork = new UnitOfWork();
        CompanyService.repository = 
            RepositoryFactory.GetRepository<ICompanyRepository, 
            Company>(CompanyService.unitOfWork);
    }

    public static IList<Company> GetOwners()
    {
        return CompanyService.GetAllCompanies();
    }

    public static IList<Company> GetAllCompanies()
    {
        return CompanyService.repository.FindAll();
    }

    public static void SaveCompany(Company company)
    {
        CompanyService.repository[company.Key] = company;
        CompanyService.unitOfWork.Commit();
    }

    public static Company GetCompany(object companyKey)
    {
        return CompanyService.repository.FindBy(companyKey);
    }
}

Come vedi quasi tutte le chiamate ai servizi sono wrapper per le chiamate al repository. È un buon esempio nella costruzione di servizi di dominio?

Dovremmo sempre avvolgere i nostri repository nei servizi di dominio? C'è un approccio migliore?

object-oriented design c# domain-driven-design java

posta Songo 21.02.2013 - 17:57

fonte

2 risposte

2

Man mano che la tua applicazione cresce, ci sono operazioni complesse che il tuo livello di servizio può avvolgere ed esporre. È davvero una facciata sul modello di dominio. Ad esempio in un'app di vendita, potresti non interessarti dell'elemento pubblicitario come oggetto discreto all'interno del modello. Devi semplicemente aggiungere articoli a un carrello, controllarli e stampare una fattura per l'utente dopo l'applicazione di eventuali sconti.

Dietro le quinte ci sono probabilmente dozzine di oggetti coinvolti nell'interazione. Il servizio potrebbe proiettare una vista appiattita del modello a oggetti in modo che quando il modello di dominio cambia dietro le quinte, il client non subisce l'impatto di tali modifiche.

risposta data 21.02.2013 - 20:41

fonte

Leggi altre domande sui tag object-oriented design c# domain-driven-design java

In che modo le strutture di controllo originali di Fortran erano insufficienti? Casi di utilizzo NoSQL [chiuso]

score 7 · Accepted Answer

Un repository è pensato per essere un'astrazione per l'archivio dati e generalmente fornisce funzionalità di recupero dei dati. Questo accordo consente, ad esempio, di modificare l'archivio dati per alcuni datastore diversi (ad esempio, da Oracle a SQL Server, anche se in pratica ciò accade raramente) e l'API del repository dovrebbe funzionare, se non è stata visualizzata alcuna dettagli specifici dell'implementazione.

Un livello di servizio, d'altra parte, è un'API destinata a essere utilizzata da qualche utente o agente esterno e fornisce servizi , non il recupero dei dati di per sé (sebbene possa fai così). Un'API di servizio può disegnare su più repository ed eseguire trasformazioni sui dati prima di servirli al client. Potrebbe avvolgere i dati in oggetti personalizzati o fornire funzionalità di impaginazione. Puoi fare cose nel tuo livello di servizio oltre la semplice memorizzazione e recupero dei dati.

Se non hai la necessità di fornire un ulteriore livello di astrazione oltre a quello fornito dal tuo repository, potresti non aver bisogno di un livello di servizio.