Come caricare pigro in modo SOA?

Question

Come caricare pigro in modo SOA?

#1 da (3 voti)
#2 da (0 voti)
#3 da (0 voti)

2

Ad esempio, ho esposto un oggetto radice in un servizio SOA, ad esempio Invoice ( Invoice ha elementi pubblicitari come figli).

A volte, ho bisogno di recuperare i suoi elementi pubblicitari di dettaglio. Sto pensando di caricarlo lentamente, perché è un overhead del traffico per trasferire elementi pubblicitari ogni volta che è richiesto Invoice . Ma in modo SOA, sembra improbabile. Perché tutto ciò che può esporre sono Invoice POCO, senza contenere alcuna logica. Quindi non posso allegare la mia pigra logica di caricamento a Invoice per istruirlo a caricare gli elementi di linea quando necessario.

soa

posta neolei 07.01.2012 - 08:59

fonte

3 risposte

0

Quello che vorrei fare è implementare una libreria client che interagisce con quel servizio e quindi utilizzare alcuni proxy per fornire il caricamento lento.

Ad esempio, il tuo servizio potrebbe restituire POCO delle fatture e POCO InvoiceLine in due chiamate separate. Ora, come utente / chiamante / client di quel servizio, puoi avere la tua libreria client che facilita l'interazione con il servizio dal codice dell'applicazione. In quella libreria client potresti avere una classe Invoice con un metodo proxy get_lines () che chiamerebbe di nuovo al servizio, ottenere i POCO InvoiceLine e restituirli (o alcuni oggetti InvoiceLine più funzionali)

Aggiorna : Ovviamente, non è possibile garantire che tutti i sistemi che chiamano il proprio servizio utilizzino lo stesso client, pertanto il Servizio non deve fare affidamento o dipendere dal fatto che la libreria client specifica esegua le chiamate. Ma per la tua applicazione, per i tuoi scopi del cliente, puoi avere qualsiasi funzionalità client desiderata (proprio come molte classi esistenti che includono le API di Google Analytics, ecc.)

risposta data 09.11.2012 - 14:38

fonte

0

Certamente vuoi ridurre il numero di round trip. Questo è un requisito realistico di qualsiasi SOA. Ciò significa che probabilmente hai molti casi d'uso che desideri codificare:

interface IInvoice
{
    Guid InvoiceId { get; }
    string InvoiceNumber { get; }
    string CustomerName { get; }
    decimal TotalPrice { get; }
}
public IEnumerable<IInvoiceSummary> FindInvoices(IInvoiceCriteria criteria);

interface IInvoiceSummary : IInvoice
{
    int NumberOfLineItems { get; }
}

public IDetailedInvoice GetInvoice(Guid invoiceId);

interface IDetailedInvoice : IInvoice
{
    ReadOnlyCollection<IInvoiceLineItem> LineItems { get; }
}

Naturalmente se hai diversi casi d'uso, potresti volerli modificare. Forse vuoi ricevere fatture non pagate per un cliente, ma in formato dettagliato, quindi forse hai un altro punto di servizio che restituisce quel caso speciale.

Quindi, ti consiglio di non creare un caricamento lento nella tua architettura SOA. Poiché il caricamento lazy nasconde il numero di round trip nel database e i round trip sono qualcosa a cui il programmatore dovrebbe sempre prestare attenzione perché sono costosi, quindi non dovresti nasconderli.

risposta data 09.11.2012 - 15:59

fonte

Leggi altre domande sui tag soa

Strumento per l'analisi del grafico su larga scala Problema algoritmico: Picking Cards

score 3 · Accepted Answer

Non c'è niente di sbagliato nel chiamare di nuovo un servizio per ottenere gli articoli della fattura. Sul livello di servizio:

ServiceInvoice LoadInvoice(Guid invoiceId) ti porterà la fattura senza i dettagli,
List<InvoiceItem> LoadDetails(Guid invoiceId) ti darà le linee.

Dopo averlo fatto, hai perso la parte OOP e il codice diventa meno intuitivo dal lato client. Per correggerlo, potresti voler aggiungere un ulteriore livello di astrazione:

class Invoice : ServiceInvoice
{
    public List<InvoiceItem> Lines
    {
        get
        {
            return MyService.LoadDetails(this.Id);
        }
    }
}