C# Servizi Strato Design Pattern

Question

Stiamo cercando nella creazione di un nuovo progetto e sono desiderosi di esplorare utilizzando i modelli di repository e livello di servizio, al fine di creare è senza bloccare il codice abbinato che è completamente verificabile tramite repository finte.

prega di vedere sotto l'idea di architettura di base. Utilizzeremo le interfacce per descrivere i repository e inserirli nei livelli di servizio per rimuovere eventuali dipendenze. Quindi utilizzando autofac, i servizi verranno cablati in fase di runtime.

public interface IOrderRepository 
{ 
    IQueryable<Order> GetAll(); 
} 

public class OrderRepository : IOrderRepository 
{ 
    public IQueryable<Order> GetAll() 
    { 
     return new List<Order>().AsQueryable(); 
    } 
} 

public class OrderService 
{ 
    private readonly IOrderRepository _orderRepository; 

    public OrderService(IOrderRepository orderRepository) 
    { 
     _orderRepository = orderRepository; 
    } 

    public IQueryable<Order> GetAll() 
    { 
     return _orderRepository.GetAll(); 
    } 
} 

public class EmailService 
{ 
    public void SendEmails() 
    { 
     // How do I call the GetAll method from the order serivce 
     // I need to inject into the orderService the repository to use 
    } 
} 

Ci sono alcune domande che stiamo avendo problemi a trovare il modo migliore di procedere.

1) Qualora il servizio sia riproducendo i metodi CRUD, così come appare possiamo essere riproducendo codice con alcun beneficio reale. O l'interfaccia utente dovrebbe chiamare direttamente i repository?

2) Cosa succede quando un servizio ha bisogno di chiamare un altro servizio. Nel nostro esempio precedente, se il servizio di posta elettronica ha bisogno di ricevere tutti gli ordini, inseriamo il servizio di ordine nel servizio di posta elettronica?

Spero che questo ha un senso

Answer 1

servizio e-mail non deve essere a conoscenza di servizi come OrderService, è necessario Mediator di lavorare sia con e-mail & & servizi d'ordine in modo che sarebbero stati disaccoppiati, o Adapter di adattarsi IOrder-IEmail:

IEnumerable<IOrder> orders = orderService.GetAll(); 

// TODO: Create emails from orders by using OrderToEmailAdaptor 
IEnumerable<IEmail> emails = ... 
emailService.SendEmails(emails); 

public sealed class EmailService 
{ 
    public void SendEmails(IEnumerable<IEmail> emails) 
    { 
    } 
} 

Mediatore:

Definire un oggetto che incapsula il modo in cui un insieme di oggetti interagisce. mediatore promuove accoppiamento lasco mantenendo oggetti dal menzionare reciprocamente esplicitamente, e permette di variare la loro interazione indipendentemente

adattatore:

Il pattern adattatore (spesso indicato come il modello involucro o semplicemente un wrapper) è un modello di progettazione che si traduce un'interfaccia per una classe in un'interfaccia compatibile

Answer 2

Cosa avrei fatto io è

1. non chiama repository direttamente dall'interfaccia utente, ma chiamare il servizio al posto e il servizio dovrebbe utilizzare il repository,

2. vorrei la chiamata al metodo dell'ordine repository dal servizio di posta elettronica, in questo modo avrei solo iniettare OrderRepository al servizio di posta elettronica (non ordinare il servizio)

Answer 3

Dai un'occhiata a Domain Driven Design. DDD trasferisce la maggior parte della logica nelle entità (Order, Email) e consente loro di utilizzare i repository.

1) Qualora il servizio sia riproducendo i metodi CRUD, così come appare possiamo essere riproducendo codice con alcun beneficio reale. O l'interfaccia utente dovrebbe chiamare direttamente i repository?

Un servizio in DDD viene utilizzato quando ci si trova a scrivere business logic al di fuori delle entità.

2) Cosa succede quando un servizio deve chiamare un altro servizio. Nel nostro esempio precedente, se il servizio di posta elettronica ha bisogno di ricevere tutti gli ordini, inseriamo il servizio di ordine nel servizio di posta elettronica?

Iniettarlo nel costruttore. Tuttavia, il servizio ordini dovrebbe inviare una e-mail, non il contrario.

L'approccio DDD sarebbe quello di creare un OrderNotificationService che prende l'evento dominio OrderCreated e compone una e-mail che invia tramite l'Aggiornamento EmailService

Mi missunderstood. La logica duplicata non è mai buona. Non metterei un metodo nel mio servizio chiamato GetAll quando il mio repository ne ha uno. Nemmeno metterei quel metodo nella mia entità.

codice Esempio:

var order = repository.Create(userId); 
order.Add(articleId, 2); 
order.Save(); // uses the repository 

Order.Send() dovrebbe creare un evento dominio che il OrderNotificationService può prendere.

Update2

Repository.Create è solo un metodo factory (google factory method pattern) per ottenere tutte le creazioni del modello di dominio in un unico luogo. Non fa nulla nel db (anche se potrebbe nelle versioni future).

Per quanto riguarda order.Save utilizza il repository per salvare tutte le righe dell'ordine, l'ordine stesso o qualsiasi altra cosa necessaria.

Answer 4

è possibile utilizzare modello adattatore o utilizzando strumenti DI

public class EmailService 
{ 
    private IOrderRepository _orderservice = null; 

    public EmailService(IOrderService orderservice) 
    { 
     _orderservice = orderservice; 
    } 

    public void SendEmails() 
    { 
     _orderService.GetAll(); 
    } 
}