Talvolta, applicazione CRUD connessa DAL

Question

Sto lavorando ad un'applicazione a volte connessa CRUD che verrà utilizzata principalmente dai team (2-4) di operatori sociali e infermieri per tenere traccia delle informazioni sui pazienti sotto forma di un piano. L'applicazione è una rivisualizzazione di un'app ASP.Net creata prima del mio tempo. Esistono circa 200 tabelle in 4 database. La versione dell'app Web si basava fortemente su SP ma poiché questa versione è un'app winform che punta a un db locale, non vedo alcun motivo per continuare con SP. Inoltre, avevo pianificato di utilizzare Merge Replication per gestire la parte di sincronizzazione e sembra che ci siano alcuni problemi con quei due insieme.

Sto cercando di capire quale approccio utilizzare per il DAL. Inizialmente avevo pianificato di utilizzare LINQ to SQL, ma ho letto bocconcini che affermano che non funziona in un'impostazione volte connessa. Ho quindi cercato di leggere e sperimentare numerose soluzioni; SubSonic, NHibernate, Entity Framework. Questa è un'applicazione relativamente semplice e a causa di un "incombente". la versione 3 riprogettare questo sforzo può essere al limite "usa e getta". L'enfasi qui è su come ottenere una versione desktop e eseguirla al più presto.

Quello che sto chiedendo qui è per chiunque abbia esperienza nell'uso di una di queste tecnologie (o una che non ho elencato) per prestarmi la tua saggezza guadagnata duramente. Qual è il mio miglior approccio, secondo te, da perseguire. Altre idee sulla creazione di questo tipo di app? Sto davvero lottando con la parte DAL di questo programma.

Grazie!

Answer 1

Se le procedure memorizzate fanno quello che vuoi, dovrei dire che sono dubbioso che otterrai benefici gettandoli via e reimplementandoli. Inoltre, non dovrebbe importare se si utilizzano procedure memorizzate o l'accesso ai dati in stile LINQ to SQL quando arriva il momento di replicare i dati nel database principale, quindi preoccuparsi di quale DAL si utilizza sembra essere un'aringa rossa.

La parte difficile delle applicazioni a volte connesse è trovare un buon sistema di risoluzione dei conflitti. I miei suggerimenti:

• Usa sempre RowGuids come chiavi primarie per le tabelle. Unisci replica funziona meglio se hai sempre nuovi record con chiave univoca.
• Renditi conto che la replica di tipo merge può fare solo così tanto: è eccezionale per riunire nuovi dati in sistemi diversi. Può persino capire gli aggiornamenti unilaterali. non può magicamente determinare che il tuo nuovo disco e il mio nuovo disco siano in realtà gli stessi né può davvero gestire i cambiamenti da entrambe le parti senza intervento umano o regole di priorità.
• Per questo motivo, avrai bisogno di " matching " regole per risolvere i record che affermano di essere nuovi, ma in realtà non lo sono. Si noti che questo è un passaggio fuzzy: raramente si può fare affidamento su una chiave univoca per essere inseriti esattamente lo stesso su entrambi i lati e senza errori. Ciò significa fornire partite ponderate in cui molti dei tuoi indicatori sono uguali o simili.
• L'interfaccia utente per la risoluzione dei conflitti e la corrispondenza tra "nuovo" e "nuovo" i record con l'originale devono essere facili da utilizzare. Uso qualcosa che sembra simile alla classica fusione a tre vie utilizzata da molti sistemi di controllo del codice sorgente: Record A, Record B, Record unito. Possono impostare automaticamente il record unito su A o B facendo clic su un pulsante di intestazione e possono selezionare ciascun campo facendo clic anche su di essi. Infine, i campi Record uniti sono aperti per la modifica, perché a volte è necessario prendere parti dell'indirizzo (diciamo) da A e B.

Nulla di tutto ciò dovrebbe influire minimamente sul livello di accesso ai dati: si tratta di un livello inferiore (replica di unione, fornita dal database stesso) o di livello superiore (risoluzione dei conflitti, fornita dalle regole aziendali per la risoluzione) rispetto al DAL .

Answer 2

Se puoi installare un sistema db localmente, scegli qualcosa che ti è familiare. Il problema più grande penso che sarà la parte di sincronizzazione e fusione. È necessario pensare a diverse possibilità: modificato qualcosa che qualcun altro ha eliminato sul server. Chi decide?

Non ho mai usato il framework Sync da solo, basta leggere un articolo. Ma questo può darti una solida base su cui costruire. Ma in ogni modo con l'accesso ai dati, la soluzione al businesslogic avrà probabilmente un impatto molto più ampio ...

Answer 3

Esiste un'app di esempio chiamata issueVision Microsoft rilasciata nel 2004.
http://windowsclient.net/downloads/folders/starterkits/entry1268.aspx

Collegamento trovato sul vecchio thread in joelonsoftware.com. http://discuss.joelonsoftware.com/default.asp?joel.3.25830. 10

Altre idee ...
Che dire della banda larga mobile? Domani funzioneranno un paio di schede cellulari 3G e la tua app non avrà bisogno di modifiche senza grandi pagine / grafica.

Foglio di calcolo Excel utilizzato nel campo. DTS o SSIS per importare i dati nell'applicazione. Mentre un "migliore" la soluzione è stata creata.

Buona fortuna!

Answer 4

Se per SP intendi le procedure memorizzate ... Non sono sicuro di capire il tuo ragionamento nel cercare di allontanarti da esse. Considerando che sono veloci, comprovati e già scritti per te (ad es. Testati).

Sicuramente, se stai realizzando un'app che imiterà l'originale, ci sono dei meriti precisi nel mantenere il maggior numero possibile di basi di codice (funzionanti) originali - il minimo dei quali è la velocità.

Proverei a installare una copia locale del db e quindi a inviare tutti i record interessati dall'ultimo periodo connesso al master db quando viene collegato.