WebService doit avoir des méthodes séparées pour remplir les propriétés dans la classe composite?

Question

Je construis un service web pour récupérer une liste d'objets composites. Une sous-propriété complexe de chaque objet de la liste doit-elle être remplie à la fois ou est-ce que le client peut demander cette information si nécessaire?

Exemple:

class InvoiceLine 
{ 
    string ServiceDescription; 
    decimal ChargeTotal; 
} 

class Invoice 
{ 
    string InvoiceNumber; 
    string CustomerNumber; 
    List<InvoiceLine> InvoiceLines; 
} 

//Returns all invoices send to this customer 
public List<Invoice> GetInvoices(string customerNumber); 

Est-ce une mauvaise conception d'avoir une autre méthode WebService comme:

public List<InvoiceLine> GetInvoiceLines(string invoiceNumber)

et nécessitent client d'abord obtenir une liste de toutes les factures enregistrées (avec liste vide de InvoiceLines en eux, et attendent d'eux d'appeler:

invoices[0].InvoiceLines = webService.GetInvoiceLines(customerNumber); 

pour simuler une "charge paresseuse".

Cela semble être un bon moyen d'économiser du volume, mais au détriment de plus d'appels pour obtenir des données en cas de besoin. Est-ce que cela en vaut la peine ou est-ce un anti-modèle quelconque?

Il ne semble pas juste de retourner un objet demi-peuplé ...

Merci à l'avance pour tous les pointeurs/liens.

Answer 1

La granularité de l'interface de service est toujours une décision importante lors de la conception de vos services. Étant donné que les appels de service Web sont généralement des appels réseau ou, à tout le moins, des appels hors processus, ils sont relativement coûteux. Si votre interface de service est trop fine (ou «bavarde»), cela peut affecter les performances. Bien sûr, vous devez tenir compte de votre application et de vos besoins lorsque vous déterminez le bon niveau de granularité. Software components: Coarse-grained versus fine-grained bien qu'un peu sec a de bonnes informations.

Il ne semble pas juste de retourner un objet demi-peuplé ...

Je suis d'accord.

Dans votre cas, supposons que InvoiceLines est coûteux à récupérer et n'est pas requis la plupart du temps. Si tel est le cas, vous pouvez encapsuler le résumé de la facture ou l'en-tête et renvoyer cette information. Toutefois, si le consommateur a besoin de la facture complète, offrez-lui la possibilité de le faire.

class InvoiceLine 
{ 
    string ServiceDescription; 
    decimal ChargeTotal; 
} 

class Invoice 
{ 
    InvoiceSummary InvoiceSummary; 
    List<InvoiceLine> InvoiceLines; 
} 

class InvoiceSummary 
{ 
    string InvoiceNumber; 
    string CustomerNumber; 
} 

public InvoiceSummary GetInvoiceSummary(string customerNumber); 
public Invoice GetInvoice(string customerNumber); 

En général, je préfère éviter d'imposer une séquence d'appels au consommateur du service. C'est-à-dire que vous devez d'abord obtenir la facture, puis vous devez obtenir les détails. Cela peut entraîner des problèmes de performances et également un couplage plus étroit entre les applications.

Answer 2

Les services Web ne doivent pas être «bavards»: vous communiquez sur un réseau, et tout échange de demande/réponse coûte du temps. Vous ne voulez pas demander au client de demander dix fois quand il pourrait demander une fois.

Laisser le client demander toutes les données à la fois.

Si cela se révèle être un problème de performance, puis permettre au client de spécifier la quantité de données qu'ils veulent, mais il devrait encore tous être retournés dans un seul appel.

Answer 3

Je ne pense pas que ce soit une mauvaise conception, je pense que c'est un compromis que vous devez considérer.Lequel est le plus important: renvoyer un graphique d'objet complet, ou les économies potentielles de transmission. Si, par exemple, vous êtes plus susceptible d'avoir des clients avec plusieurs centaines de milliers de InvoiceLines et que vous n'avez besoin que de ceux dans des circonstances très spécifiques, il semble très logique de les séparer de la manière dont vous le mentionnez.

Cependant, si vous avez presque toujours besoin du InvoiceLines, et que vous ne parlez que 10 instances, il est plus logique de toujours les envoyer ensemble.