Qualsiasi ORM che funziona con MS-Access (per la prototipazione)?

Question

Sono alle prime fasi di un progetto e non è ancora chiaro se avremo bisogno di un database "reale" (ad esempio SQL Server et al). Così ho fatto alcuni prototipi usando MS-Access, che sta funzionando bene finora. (sviluppo in C#/VS2008/.Net 3.5/MS-Access 2000).

Tuttavia, il disaccoppiamento dell'impedenza relazionale dell'oggetto sta già diventando fastidioso e peggiorerà solo con l'evolversi del progetto.

Non sono stato in grado di trovare un ORM che funzioni con MS-Access. Eventuali suggerimenti?

Edit - Follow Up Abbiamo finito per usare Fluent NHibernate, soprattutto perché Automaps il nostro modello a oggetti per un database relazionale, che è stata una grande vittoria per noi. La maggior parte degli esempi di codice FNH che abbiamo trovato utilizzato SQLite, e ha funzionato così bene che intendiamo usarlo per il nostro database di produzione. (L'app è un pacchetto di raccolta e analisi dei dati scientifici desktop).

Answer 1

I file MSAccess possono essere impostati come origine ODBC su macchine Windows. Quasi tutti gli ORM ti permetteranno di usare ODBC. Here è un breve tutorial su come impostarlo, è delineato per Win2k ma il processo è lo stesso per XP +. È inoltre necessario installare MDAC sulla confezione.

Anche NHibernate ha il supporto nativo di MSAccess, vedere here. Non l'ho mai usato però. Ha anche un ODBC driver.. Molti altri supportano anche ODBC.

E ancora, come altri stanno dicendo .. MSAccess non scala ... periodo. Installare un vero server di database è abbastanza semplice, quindi consiglierei SQL Server Express come altri, o anche MySQL o Postgre, qualunque sia più facile da configurare.

Se si tratta di un'applicazione che si desidera distribuire ai client, con ogni client con un proprio database univoco, consiglierei un'altra soluzione interamente, SQLite. SQLite ti dà il potere del database su un'app in base all'app. Se si dispone di un server di database centrale, una delle soluzioni menzionate in precedenza sarebbe la migliore.

Answer 2

non si può dare una risposta alla tua domanda, ma invece di accesso che si potrebbe prendere in considerazione una delle seguenti opzioni:

• SQL Server Express: è gratuito e compatibile con il pieno di SQL Server
• SQL Server Compact: anche gratuito, non richiede alcuna installazione/installazione, non supporta tutte le funzionalità (ad es. Nessuna stored procedure).

Answer 3

In questa fase, se non si è sicuri se è necessario un database "reale" oppure no, salterò MS Access e andrò direttamente a SQL Server Express. È gratuito e ti consente comunque di fare tutto il necessario.

Inoltre, se in un secondo momento decidi di ridimensionarlo, puoi farlo senza alcun dolore.

Answer 4

C'è solo uno scenario al momento di scegliere il motore di database di Access è una buona scelta: quando si costruisce un'applicazione di Access autonomo utilizzando le forme di accesso (anche se la scelta di utilizzare Access, in primo luogo è una scelta discutibile;)

Il motore di database con cui VS2008 funziona meglio è SQL Server e non avrai problemi a trovare un ORM che giochi con SQL Server.

Answer 5

Si consiglia di utilizzare qualcosa come Microsoft SQL Server o PostgreSQL per la prototipazione. Se non si desidera imparare la sintassi SQL specifica e installare strumenti speciali per la progettazione dello schema del database, è possibile utilizzare ORM che genera automaticamente lo schema del database dalla dichiarazione delle classi persistenti. In ogni caso questo approccio è molto efficace per la prototipazione.

Answer 6

LLBLGen lavora con accesso

Answer 7

L'accesso è solo una cattiva, cattiva idea. Credo che MS includa solo l'accesso in Office per mantenere gli utenti legacy felici.

Anche se si trova un ORM che funziona con un database di Access, con poche eccezioni si sta bloccando in uno strumento di nicchia che probabilmente non funzionerà immediatamente con un vero motore di database. Se in seguito decidi di passare a un vero motore di database, non dovrai solo gestire la migrazione del database, ma passare a un ORM diverso.

See this comparison between SQL Server Express and SQL Server Compact. Il documento di confronto menziona anche alcuni problemi con altri archivi di dati, incluso Access.

se siete veramente preoccupati per essere in grado di installare SQL Server Express, prendere in considerazione SQL Server Compact:

• può essere collegato nella vostra applicazione ridistribuibile. Non è necessario installare un servizio (che potrebbe richiedere diritti di amministratore durante l'installazione dell'applicazione); tutto è a posto quando installi la tua app. Questo ha più senso se hai bisogno che i dati risiedano sulla macchina dell'utente invece che su un server, ed è più simile all'utilizzo di Access.

• è meno potente di Express (non supporta le viste, trigger, stored procedure, che io considero un requisito)

• può essere scalata fino a Express o altre versioni di SQL Server molto facilmente

• Adatto ingombro ridotto installa come compresse, dispositivi portatili, ecc

tenere sempre scalabilità nella pianificazione di qualsiasi applicazione. Non vuoi finire di dover scrivere un compilatore PHP-> C++ se/quando la tua app ha successo solo perché hai scelto lo strumento sbagliato.

Mentre siamo in argomento:

Il grande problema con Access (o, in questo caso, il motore Jet, che è la parte che ci realmente utilizzare per l'integrazione di un database di Access con un App .NET) è che non esiste un "server" che gestisce le richieste di datase. Il motore, ospitato nella tua app, deve leggere e scrivere direttamente su un file su disco che contiene il database. Ogni volta che ciò accade, il file deve essere bloccato per impedire le scritture simultanee. Le letture sporche diventano più comuni con la crescita del numero di utenti, così come il potenziale di corruzione del database.

Immagina di avere ogni cliente in un grande ristorante che tenta di entrare contemporaneamente in cucina per scrivere gli ordini o recuperare il cibo. Il caos sarebbe risultato. Ci sarebbero un sacco di piatti rotti, la cucina sarebbe un disastro, avresti la fortuna di ottenere ciò che hai ordinato in qualsiasi condizione commestibile. Con un cliente, questo probabilmente funziona bene. Con 5, eh, forse. Con 20,50,1000? Non così tanto.

Così, l'industria della ristorazione ha introdotto camerieri e manager che tamponano IO in cucina.L'applicazione server di database fa qualcosa di analogo a ciò restringendo l'accesso ai file sul disco. Ognuno ottiene quello che vuole, più veloce e in un modo molto più affidabile, e l'archivio dati è protetto.