Buone tecnologie per lo sviluppo di un componente server modulare in .net?

Ci sono un paio di buone linee guida da seguire per garantire la modularità dei componenti lato server, una buona regola empirica da tenere a mente mentre si progettano gli assiemi e i loro limiti di responsabilità possono essere tali da rendere più facile soddisfare lato client richiede in-proc sul lato client. Ciò ti aiuterà a progettare il componente lato server in modo che sia in grado di completare le attività in più scenari in modo più pulito.

Suggerirei di leggere questo: link

Detto questo, ecco i miei suggerimenti generali:

• DI, sì. Comunque lo fai, usalo per astrarre i livelli del servizio.
• Progetta e implementa il punto cruciale di ciò che vuoi che il tuo side server sia, in una libreria di classi senza riferimenti a parti di servizio
• Riconoscere il fatto che si tratta di un "servizio" è semplicemente un effetto del suo processo di hosting e non dovrebbe essere un pezzo intrinseco della logica aziendale stessa.
• Al minimo , la segmentazione orizzontale dovrebbe creare un confine tra l'hosting del servizio e i componenti logici, probabilmente per la modularità vorrai più limiti orizzontali di questo.
• Crea tutto sotto il tuo livello di hosting, ignorando il più possibile gli altri servizi. Vuoi che le dipendenze esterne rimangano il tuo grafico il più vicino possibile alla cima della pila.

I servizi WCF e MVVM sono più che sufficienti per fornire la funzionalità che descrivi in modo liberamente accoppiabile, modulare e scalabile.

Sospetto che la tua confusione potrebbe provenire dalla visualizzazione del modello e dei servizi WCF come solo un mezzo per recuperare i dati. Tuttavia, un servizio può essere molto più di un altro livello nella pila di feed di dati. I servizi possono essere utilizzati per attivare azioni ad hoc, calcoli o qualsiasi altra cosa possa richiedere la tua applicazione. Inoltre, i servizi Modelli e possono essere entrambi composti da chiamate a uno o più altri servizi.

A un livello astratto, un servizio è semplicemente una funzione invocabile che soddisfa un contratto. Non importa se le azioni del contratto sono orientate ai dati o al server.

I tuoi modelli potrebbero non avere molto per loro se tutto ciò che è richiesto è invocare un particolare servizio senza scambiare dati oltre a token di autenticazione, se non addirittura quello. Ciò è perfettamente a posto in alcuni scenari, a seconda di cosa sta facendo il servizio.