Quanta logica aziendale appartiene al livello dei servizi RIA?

Question

Recentemente ho sperimentato con Silverlight, Servizi RIA e Entity Framework utilizzando .NET 4.0. Sto cercando di capire se questo stack ha senso per l'uso in uno dei miei progetti futuri. Sembra senz'altro che queste tecnologie possano essere molto produttive per lo sviluppo di applicazioni, ma non riesco a decidere come architettare un'applicazione in cima a questo stack.

Il problema principale che ho riscontrato è che nella maggior parte delle demo ho visto che la maggior parte della logica aziendale termina come DataAnnotation e convalida personalizzata nella classe del servizio di dominio dei servizi RIA. Questo mi sembra inopportuno. Considero il servizio di dominio fondamentalmente un servizio web glorificato che rende facile inviare informazioni al client. Ma la maggior parte di ciò che ho visto sembra orientare il servizio di dominio come la principale fonte di business logic nell'applicazione.

Quindi, le mie domande:

• Qual è la posizione migliore per la logica di business (le regole, le convalide, i comportamenti, autorizzazione) in un'applicazione che utilizza questo stack?
• Esistono linee guida pubblicate a livello di architettura per l'utilizzo di questo stack?

Le mie domande riguardano applicazioni grandi, complesse e di lunga durata. Ovviamente per un'applicazione di pochi schermi questo è meno preoccupante.

Edit: Un'altra cosa che ho intenzione di menzionare è che, ovviamente, si può fare la classe di servizio del dominio stupida, ma poi si perde un sacco di informazioni dell'entità automagic (ad esempio le convalide) essere spinto al cliente. E poi se perdi c'è un punto utile nell'utilizzo dei servizi RIA?

Answer 1

Il nostro team sta implementando un'applicazione di Silverlight sullo stack RIA. Abbiamo deciso di creare un modello di dominio in cima alle entità RIA. Inoltre, abbiamo scelto di seguire il modello MVVM per modellare le interazioni dell'interfaccia utente.

Finora, ho notato i seguenti vantaggi:

1. classi di dominio sono un bel posto dove mettere la logica di business tra cui convalide complesse.
2. Le classi di dominio utilizzano le entità RIA e il contesto come interfaccia per l'archivio dati.
3. Le classi di dominio sono modellate in base alle esigenze aziendali e non richiedono una relazione uno-a-uno con le entità RIA.
4. Le convalide semplici dell'interfaccia utente possono essere visualizzate in ViewModels.

Un'altra cosa da notare è che abbiamo implementato la nostra mappa di identità per la concorrenza e spinto il tracciamento sporco nel contesto RIA.

In pratica, questa architettura richiede un po 'più sforzo di codifica, ma ripaga a lungo con leggibilità e manutenibilità. Anche per semplici applicazioni CRUD, seguirei questa pratica. Avere la capacità di costruire un modello di dominio che rappresenti più accuratamente lo spazio del problema è un vantaggio avvincente.

Answer 2

In generale è più produttivo lavorare con la tecnologia che contro.

Come dici tu la logica di business finisce in DataAnnotations e validazioni personalizzate, questo potrebbe essere il "miglior" posto per esso rispetto alla produttività degli sviluppatori, per la prima versione del sistema.

Ho la sensazione che questa tecnologia abbia il suo punto di forza quando si creano rapidamente applicazioni crude, quando si hanno complicate logiche di business si può finire con un ulteriore livello aziendale tra l'applicazione Silverlight ei servizi RIA.

Non ho ancora provato a costruire qualcosa di reale in questo, sapremo davvero la risposta a questo dopo averlo usato per un po 'di tempo.