Estrarre i livelli di connessione dati e i livelli di presentazione in un'applicazione enterprise

Question

Stiamo costruendo un'applicazione enterprise in cui incorporeremo più piattaforme per interfacce utente (ad es. webapp ASP.net, applicazioni Windows e un giorno, app mobili) e piattaforme multiple per database back-end (es. SQL Server, XML, Oracolo). Un'ulteriore necessità è che questi DB back-end siano centralizzati e accessibili via web o localizzati sul computer client e occasionalmente sincronizzati con il server centrale.

Qualcuno può dare consigli su come possiamo astrarre il livello dell'interfaccia utente & amp; il livello dati in modo da poter creare più semplicemente l'adattabilità plug-and-play tra le varie interfacce utente e le varie scelte per i DB? Ad esempio: in un caso, potremmo avere un'app Web in esecuzione su un server centralizzato tramite Internet e potremmo avere macchine remote che eseguono copie localizzate tramite un'app di Windows. A intervalli pianificati, vorremmo sincronizzare tutte le macchine in modo che possano avere tutti i dati quasi in tempo reale.

Abbiamo anche bisogno di consigli su come gestire le varie stringhe di connessione coinvolte in modo che l'unica impostazione che dovrebbe essere modificata su una qualsiasi app sia "locale". o " remote " ;, che determinerebbe quindi la stringa di connessione necessaria.

Answer 1

Astrarre il livello di presentazione è un concetto abbastanza semplice dopo aver appeso l'architettura n-tier. Concentrati solo sulla differenziazione della "logica di dominio" dalla "logica dell'applicazione". La logica del dominio è comune tra le diverse piattaforme e la logica dell'applicazione è specifica della piattaforma. Ad esempio, la convalida dei dati è una logica di dominio (anche se è bello quando puoi farlo sul front-end, il che rende le cose più complesse, ma lavora con me qui ...) e decide a quale URL reindirizzare dopo che qualche azione è l'applicazione logica. Assicurati di mettere la logica del tuo dominio a un livello utilizzabile da qualsiasi piattaforma e assicurati di non inserire alcuna logica dell'applicazione nel tuo livello di dominio.

L'altra metà della domanda sembra concentrarsi maggiormente, ma vorrei chiedere alcuni chiarimenti qui, in quanto posso discernere due diverse domande essenziali.

1. Spero non stia andando per il "santo graal" di indipendenza del database. Questo è sempre un obiettivo elevato raggiunto durante la fase di progettazione, che quasi sempre, praticamente ogni volta, non è necessario.

   Se non è quello che stai cercando, ti suggerirei di sapere quali oggetti sono memorizzati in quale mezzo di persistenza, e dovresti evitare la complessità della flessibilità e semplicemente codificare i tuoi percorsi verticali come inoltrare un modo il più possibile. IE non codifica cose extra in alcune business class che memorizzano i suoi dati in Oracle per consentirti di metterle in SQL Server "ad un certo punto in futuro". (Sono tornato indietro all'indipendenza del database, no?)

2. La questione della memorizzazione nella cache dei dati a livello locale per migliorare le prestazioni di determinate piattaforme è specifica per tali piattaforme e suggerirei di esaminare gli Smart Client e il framework / guida Caching del team MS P & amp; P. Negli ultimi due anni ho lavorato piuttosto esclusivamente su materiale web, ma nel 05/06 è stato abbastanza buono e nel frattempo hanno lavorato molto sui loro contenuti Smart Client.

Answer 2

Vorrei utilizzare il modello del provider per stabilire le connessioni al database nella tua applicazione.

Vorrei iniziare guardando gli esempi e i dettagli forniti in Microsoft Data Application Block, penso che ti aiuterà a farti strada.