Come fai a sapere se dovresti usare entità di auto-monitoraggio o DTO / POCO?

4

Quali sono alcune domande che posso chiedermi sul nostro design per identificare se dovremmo utilizzare DTO o entità di auto-monitoraggio nella nostra applicazione?

Ecco alcune cose che so di prendere in considerazione:

  • Abbiamo un'applicazione di livello n standard con un client WPF / MVVM, un server WCF e un database MS SQL.
  • Gli utenti possono definire la propria interfaccia, quindi i dati necessari al servizio WCF cambiano in base all'interfaccia che l'utente ha definito autonomamente
  • I modelli vengono utilizzati sia sul lato client che sul lato server per la convalida. Non saremmo vincolanti direttamente con DTO o STE
  • Alcuni modelli contengono proprietà che vengono caricate in modo pigro dal servizio WCF, se necessario
  • Esistono controlli delle autorizzazioni sul lato server che influiscono sul modo in cui i dati vengono restituiti. Ad esempio, alcuni dati sono parzialmente o completamente mascherati in base al ruolo dell'utente
  • Le nostre risorse sono limitate (tempo, manodopera, ecc.)

Quindi, come posso determinare cosa è giusto per noi? Non ho mai usato EF prima di allora, quindi non so davvero se STE è giusto per noi o meno.

Ho visto persone suggerire di iniziare con STE e implementare solo DTO se diventano un problema, ma al momento disponiamo di DTO e stiamo cercando di decidere se l'utilizzo di STE renderebbe la vita più facile. Siamo abbastanza precoci nel processo che il passaggio non sarebbe un grosso problema, ma non voglio passare a STE solo per scoprire che non funziona per noi.

    
posta Rachel 23.03.2011 - 16:30
fonte

1 risposta

3

L'argomento principale contro le "entità di auto-localizzazione" (o il pattern ActiveRecord, come ho sentito chiamare) è che mescola la logica di persistenza nel tuo modello di dominio. L'alternativa POCO ti offre una migliore separazione delle preoccupazioni.

Considerare il caso in cui si potrebbe avere il modello operativo in un ambiente client o server. È possibile astrarre la logica di persistenza in un'interfaccia del repository. Durante l'esecuzione nell'ambiente server, è possibile iniettare il modello con un repository che persiste le entità nel database, ma quando sul client è possibile iniettare lo stesso modello con un repository che persiste le entità su un servizio WCF. La logica di test dell'unità può anche iniettare un deposito fittizio.

Il vantaggio del pattern ActiveRecord è che di solito c'è un sacco di automazione, quindi punti l'IDE in un database e costruisci tutte le tue entità per te. Con le entità POCO, di solito fai un po 'più di programmazione. Personalmente preferisco la flessibilità che questo offre con l'alternativa POCO.

    
risposta data 23.03.2011 - 16:42
fonte

Leggi altre domande sui tag