Qual è lo standard per la progettazione di entità / connettività di database per un database mySQL?

Question

Qual è lo standard per la progettazione di entità / connettività di database per un database mySQL?

#1 da (3 voti)

4

Sto ospitando una soluzione che funge da livello web su una macchina Ubuntu con Apache e Mono. Attualmente sto sviluppando il progetto su OSX, usando Mono. Capisco che non ci sia un supporto nativo per Linq per SQL in Mono, quindi ho iniziato a frequentare la vecchia scuola e ho sviluppato procedure memorizzate per l'interazione con il mio database. Io uso ADO.NET per la connettività.

Lo sviluppo è faticosamente lento. Ogni volta che apporto una modifica a una stored procedure, devo aggiornare i campi su tutta la mia architettura. Sono diventato molto pigro in termini di possibilità di eliminare facilmente un'entità in Linq in SQL e di avere gli oggetti aggiornati con nuovi campi.

Sembra che lo sviluppo stia impiegando 10 volte il tempo necessario in .NET in Windows.

Esiste un'architettura migliore che potrei utilizzare per la connettività del mio database?

Mentre la metodologia a cui sto aderendo è semplice e funziona bene, è semplicemente un approccio lento.

mysql osx mono ubuntu

posta George 09.08.2011 - 18:48

fonte

1 risposta

Leggi altre domande sui tag mysql osx mono ubuntu

Ci sarà qualche LINQ ufficiale come una libreria basata su lambda per C ++? [chiuso] Esiste una guida pratica al processo software del team?

score 3 · Answer 1

Bene, potresti usare un DataMapper (spesso chiamato " object relational mappers ") per fornire servizi di persistenza alla vostra applicazione. LinQ-To-SQL è fondamentalmente anche un DataMapper.

I buoni DataMappers sono ad esempio NHibernate e Subsonic , che può essere utilizzato con una varietà di database. Microsoft ha anche introdotto il ADO.NET Entity Framework alcuni anni fa, che probabilmente ha migliorato il design supporto temporale in Visual Studio rispetto ad entrambi gli altri.

Ecco anche un confronto di ORM .

Personalmente, uso (N) Hibernate abbastanza spesso. Fa un ottimo lavoro quando vuoi davvero un modello persistenza-ignorante ed è molto maturo.

Tuttavia, non so se accelererà così tanto il tuo sviluppo. Spesso i tempi dei campi devono essere trascinati attraverso l'intera applicazione. È solo un dato di fatto. Con un ORM, devi per lo più aggiungere il campo all'entità, al database e alla mappatura. Dubito che sia molto meglio del tuo attuale scenario.

Nel classico ADO.NET con set di dati digitati è sufficiente modificare le query di DataAdapter e lo schema del set di dati, che non è molto peggiore per la soluzione ORM. Il tuo problema è probabilmente il livello noioso della procedura. Un livello di procedura è solo una buona idea quando si desidera limitare l'accesso ai dati per i propri utenti (database).

Penso che il tuo vero problema sia la mancanza del supporto del tempo di progettazione per la tua attuale architettura.