Service Layer per recuperare dati specifici per le viste

Question

Service Layer per recuperare dati specifici per le viste

#1 da (1 voti)

1

Sto costruendo un'applicazione WPF, usando MVVM e Prism. Vale la pena notare che io sono l'unico sviluppatore che lavora su un grande progetto, quindi le risorse sono limitate. Ecco cosa ho attualmente:

Modelli - POCO
ViewModels - contengono istanze di POCO e utilizza il livello di servizio in base all'interazione dell'utente.
Visualizzazioni - associate a ViewModels
Servizi - Servizi WCF per persistenza, recupero dati

Uso Dapper per mappare i risultati delle query sui miei modelli.

Sono curioso di sapere come gli altri, che non usano un ORM, gestiscono il recupero dei dati dato che una miriade di variazioni se restituisce l'oggetto POCO completamente caricato causerebbe un'esecuzione di query piuttosto significativa.

per es.

public class Customer : BindableBase
{
   public string Name{ get; set; }
   public ObservableCollection<Address> Addresses { get; set; }
   public ObservableCollection<Contact> Contacts { get; set; }
}

public class Contact : BindableBase
{
   public ObservableCollection<PhoneNumber> PhoneNumbers { get; set; }
}

Quando guardi i risultati di ricerca per i clienti, potremmo visualizzare solo il nome. Quindi una query come SELECT Name FROM dbo.Customer sarebbe sufficiente.

Quando si modifica un record del cliente, abbiamo bisogno della maggior parte dei dati recuperati relativi al record del cliente, quindi ci sarebbero dei join nella query per afferrare indirizzi, contatti e numeri di telefono.

... e ci sono altre opzioni, forse hanno solo bisogno di indirizzi o solo contatti.

Il livello di servizio verrà utilizzato in altre applicazioni e tecnologie e, in quanto tale, avrò la logica della mia attività come posizione centralizzata. Sarò bloccato a creare una funzione nel livello di servizio per gestire ogni scenario? PER ESEMPIO. GetSearchData(string searchCriteria) ... GetCustomerWithAddresses(int customerId) ... se sì, come andresti a strutturare il progetto? Ho letto da qualche parte che un'altra persona ha il livello di servizio che restituisce il modello di visualizzazione, di cui non sono necessariamente un fan. Avrei ancora bisogno delle funzioni generiche che restituiscono i dati di base per altre tecnologie che consumano i servizi.

web-services services

posta Chris Klepeis 02.10.2015 - 15:21

fonte

1 risposta

Leggi altre domande sui tag web-services services

Come e dove testare se gli oggetti di richiesta JSON generati dal front-end sono validi Metodi per prevenire lo SPAM con un'API - Modulo di contatto del sito Web di AngularJS

score 1 · Accepted Answer

Di solito con un oggetto Cliente lo popolerei completamente. Sebbene tu voglia la possibilità di più indirizzi ecc. Di solito ne hai solo uno o due e tendi ad avere a che fare con un singolo cliente alla volta.

Tuttavia, se inizi ad avere molti oggetti secondari o hai a che fare con molti clienti contemporaneamente (ad esempio per un rapporto) rimuoverei tutti gli oggetti secondari (di solito uso poco per indicare solo oggetti semplici) ed espongo le relazioni tramite il repository.

es

repo.GetAddressesForCustomer(customerId)

class Address 
{
    string CustomerId {get;set;}
    ...
}

Ciò ti consente di limitare i dati restituiti solo a ciò che è necessario e anche di ottimizzare le query per il set di dati specifico che desideri recuperare.

Ad esempio, vogliamo mostrare un elenco di clienti con ordini attivi, che mostrano id, nome e codice postale dell'indirizzo primario.

Caricando l'intero oggetto uno alla volta si otterrebbero n + 1 query db, anche se caricassimo pigro via EF o qualche altro ORM intelligente potremmo finire con una query inefficiente con wierd joins. Ma se manteniamo il controllo sul livello del repository possiamo popolare il nostro modello di visualizzazione con

repo.GetCustomersWithActiveOrders();
repo.GetPrimaryAddressesOfCustomersWithActiveOrders();