2015-05-19 24 views
9

Attualmente sono all'inizio dello sviluppo di un'applicazione Web di grandi dimensioni contenente principalmente una SPA angolare e una WebAPI OData con accesso a un livello di back-end.
Siamo in una fase iniziale e abbiamo iniziato a implementare le prime classi incluso uno Model.dll che si trova in uno spazio dei nomi comune in modo che sia accessibile a tutti i livelli.
Stiamo discutendo di questi DTO all'interno del modello. Alcuni dicono che l'uso di interfacce è assolutamente necessario, quindi il codice sarebbe simile a questo:Interfacce per DTO

namespace MySolution.Common.Model 
{ 
    public interface IPerson 
    { 
     int Id { get; set; } 
     string Name { get; set; } 
     ... 
    } 
} 

namespace MySolution.Common.Model 
{ 
    public class PersonDTO : IPerson 
    { 
     public int Id { get; set; } 
     public string Name { get; set; } 
     ... 
    } 
} 

Quindi è tutto. Solo semplici DTO senza più intelligenza.
Ora mi sto chiedendo se questo è davvero un buon approccio, perché non vedo la necessità di utilizzare l'interfaccia qui.
Quali sono i vantaggi di questo? È stata citata la testabilità, ma è anche necessario testare i DTo? Anche l'iniezione di dipendenza non dovrebbe essere il punto.
Qualsiasi illuminazione sarebbe molto utile. Alla fine l'apprendimento di nuove cose e approcci è sempre buono ...

+0

Non c'è motivo di usare un'interfaccia se non ne hai bisogno. Questo sta complicando quello che dovrebbe essere un oggetto semplice. –

+1

Se * DTO * è semplicemente un elenco di proprietà, vedo questo inutile. Se avessi un qualche tipo di repository, dovresti interfacciarlo per sostituire una connessione DB per una rappresentazione falsa, per esempio. Se tu avessi 'Person GetPerson()', potresti avere la versione DB e la versione Fake. – christiandev

+0

È possibile inserire un'interfaccia marker su un DTO ('FooDto: IAmADto') per i vincoli di tipo e le mappature, ma in caso contrario, quale scopo serve? Non c'è astrazione qui, a seconda di 'IPerson' ti dà esattamente lo stesso livello di accoppiamento a seconda di' Persona'. –

risposta

3

DTOs transfer state - questo è tutto. Iniettarli attraverso un contenitore o deriderli per il test sembra inutile (se questa è la motivazione) e del tutto inutile. Non farlo

2

A titolo di esempio, in seguito al mio commento sopra:

Interface IRepo 
{ 
    Person GetPerson(int id); 
} 

Public class DbRepo : IRepo 
{ 
    public Person GetPerson(int id){//get person from database} 
} 

Public class FakeRepo : IRepo 
{ 
    public Person GetPerson(int id) 
    { 
    return new Person {Id = id, Name = "TestName"}; 
    } 
} 

usereste un FakeRepo con alcuni oggetti mock a scopo di test.

+0

Lo capirei per usare l'interfaccia per quel caso. Nel mio caso ottengo oggetti da un altro servizio che può essere un database in qualsiasi momento e mappare tali oggetti sul mio DTo usando 'Automapper'. –

+0

Come menzionato nel commento sopra, è inutile avere un'interfaccia per un semplice DTO. – christiandev