Come progettare oggetti di trasferimento dati in Business Logic Strato

Question

DTO

Sto costruendo un'applicazione Web Vorrei scalare a molti utenti. Inoltre, ho bisogno di esporre la funzionalità a terze parti fidate tramite Web Services.

sto usando LLBLGen per generare il livello di accesso ai dati (utilizzando SQL Server 2008). L'obiettivo è quello di costruire un livello di logica di business che protegge il Web App dai dettagli di Dal e, naturalmente, per fornire un ulteriore livello di convalida al di là del DAL. Inoltre, per quanto posso dire in questo momento, il servizio Web sarà essenzialmente un involucro sottile sopra la BLL.

Il DAL, naturalmente, ha il proprio insieme di oggetti entità, per esempio, CustomerEntity, ProductEntity, e così via. Tuttavia, non voglio il livello di presentazione di avere accesso a questi oggetti direttamente, in quanto contengono metodi specifici Dal e il gruppo è specifico per il DAL e così via. Così, l'idea è di creare Transfer Data Objects (DTO). L'idea è che questi sarà, in sostanza, il buon vecchio C # /. Oggetti NET che hanno tutti i campi, per esempio, un CustomerEntity che sono in realtà la tabella del database clienti, ma nessuna delle altre cose, tranne forse alcune proprietà IsChanged / IsDirty. Quindi, non ci sarebbe CustomerDTO, ProductDTO, ecc presumo questi avrebbero ereditato da una classe base DTO. Credo di poter generare questi con qualche modello per LLBLGen, ma non sono sicuro a questo proposito ancora.

Quindi, l'idea è che il BLL esporrà la sua funzionalità accettando e restituendo questi oggetti DTO. Credo che il servizio Web consente di gestire la conversione di questi oggetti per XML per i terzi di usarlo, molti non possono fare uso di .NET (anche, alcune cose saranno copione richiamabile da AJAX invita la Web App, utilizzando JSON).

Non sono sicuro che il modo migliore per progettare questo e esattamente come andare avanti. Qui ci sono alcuni problemi:

1) Come questo dovrebbe essere esposto ai clienti (Il livello di presentazione e per il codice Web Service)

Io pensavo che ci sarebbe stata una classe pubblica che ha questi metodi, ogni chiamata sarebbe essere un'operazione atomica:

InsertDTO, UpdateDTO, DeleteDTO, GetProducts, GetProductByCustomer, e così via ...

Poi i clienti sarebbe solo chiamare questi metodi e passare gli argomenti appropriati, tipicamente un DTO.

E 'questo un buon approccio praticabile?

2) Cosa tornare da questi metodi? Ovviamente, il tipo Get / Fetch di metodi tornerà DTO. Ma che dire di inserti? Parte della firma potrebbe essere:

InsertDTO(DTO dto)

Tuttavia, quando si inserisce quello che dovrebbe essere restituito? Voglio essere notificato di errori. Comunque, io uso le chiavi primarie autoincrementing per alcune tabelle (Tuttavia, pochi tavoli hanno le chiavi naturali, in particolare molti-a-molti quelli).

Una possibilità ho pensato era una classe Risultato:

class Result
{
    public Exception Error {get; set;}
    public DTO AffectedObject {get; set;}
}

Quindi, su un inserto, il DTO otterrebbe il suo ID get (come CustomerDTO.CustomerID) insieme di proprietà e poi mettere in questo oggetto risultato. Il cliente sa se esiste un errore se Result.Error! = Null e poi sarebbe conoscere l'ID dalla proprietà Result.AffectedObject.

E 'questo un buon approccio? Un problema è che sembra che sta passando un sacco di dati avanti e indietro che è ridondante (quando è solo l'ID). Non credo che l'aggiunta di un "int NewID" proprietà sarebbe pulito perché alcuni inserti non avranno una chiave autoincrementing del genere. Un altro problema è che non credo che i servizi Web potrebbero gestire questo bene? Credo che sarebbe solo restituire il DTO base per AffectedObject nella classe Risultato, piuttosto che il DTO derivata. Suppongo che ho potuto risolvere questo avendo un sacco di diversi tipi di oggetti risultato (forse derivato da un risultato di base ed ereditare la proprietà Error), ma che non sembra molto pulito.

Va bene, spero che questo non è troppo prolisso ma voglio essere chiaro.

Answer 1

1: Questo è un approccio piuttosto standard, che ben si presta ad un'implementazione "repository" per il miglior approccio unità controllabile

.

2: Eccezioni (che dovrebbe essere dichiarato come "difetti" sul confine WCF, btw) avranno sollevato automaticamente. Non è necessario per gestire tale direttamente. Per i dati - ci sono tre approcci comuni:

• uso ref sul contratto (non molto carina)
• restituire l'oggetto (aggiornato) - vale a dire public DTO SomeOperation(DTO item);
• ritorno solo le informazioni di identità aggiornato (chiave primaria / timestamp / etc)

Una cosa su tutte queste è che non richiede un diverso tipo per operazione (contrastare la classe Result, che avrebbe bisogno di essere duplicato per DTO).

Answer 2

Q1: Si può pensare i tipi di compositi WCF Data contratto DTOs per risolvere questo problema. Questo strato l'interfaccia utente così ha accesso solo alle proprietà DataMember del DataContract. Le operazioni atomiche sarebbero i metodi esposti dal WCF Interface.

. Domanda 2: Configurare i contratti di dati di risposta per restituire un nuovo tipo personalizzato con le vostre chiavi primarie ecc ... WCF può anche essere configurato per eccezioni bolla torna l'interfaccia utente