Meglio eseguire delle If in una stored oppure richiamare da codice più...

venerdì 20 febbraio 2015 - 10.40

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

Elenco Tags VB.NET

trinity Profilo | Guru

3.465 messaggi | Data Invio: ven 20 feb 2015 - 10:40

Salve ragazzi,
in base a delle opzioni lato code behing fornite dall'utente, devo eseguire diverse query sql scritte in una stored procedure.
Adesso secondo voi, a livello di prestazioni ovviamente, è meglio eseguire delle IF...che mi permettono di eseguire determinate query in una sola stored, oppure creare e richiamare da codice diverse stored in base a quello che mi serve?

Esempio

@flag (è un parametro)

if @flag=1
BEGIN
SELECT
....
END
if @flag=2
BEGIN
SELECT
.....
END

e così via.... oppure creo 3 stored diverse e le richiamo da code behind a seconda dell'opzione attivata?

grazie ciao
Cirillo Fabio
www.trycontact.com
www.wondernet.biz
fabio@wondernet.biz
http://blogs.dotnethell.it/fabiocirillo/
http://wnetsoftware.blogspot.com

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: ven 20 feb 2015 - 12:02

>Salve ragazzi,
ciao

>Adesso secondo voi, a livello di prestazioni ovviamente, è meglio
>eseguire delle IF...che mi permettono di eseguire determinate
>query in una sola stored, oppure creare e richiamare da codice
>diverse stored in base a quello che mi serve?
A livello di prestazioni cambia molto poco, direi quasi niente. Il fatto è che ci sono alcune domande che mi farei:
- Tutte le chiamate in ogni caso tornano lo stesso resultset?
- Ha senso (o meglio porta vantaggi) mettere la logica di business sul db andando di fatto ad accoppiarsi alla base dati?
- Se le chiamate non tornano ma fanno qualcosa (comandi di salvataggio ad esempio), ha senso portare la logica sul database?

Secondo me devi capire bene dove ti servono quelle logiche, perchè farle a db mi sembra un po' eccessivo.
Mi piace tenerlo snello per avere il pieno controllo di quello che il database fa come relazionale, non come layer di astrazione di logica.

>grazie ciao
di nulla!

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/en-us/mvp/Alessandro%20Alpi-4014222

trinity Profilo | Guru

3.465 messaggi | Data Invio: ven 20 feb 2015 - 13:20

>>Salve ragazzi,
>ciao
ciao
>>Adesso secondo voi, a livello di prestazioni ovviamente, è meglio
>>eseguire delle IF...che mi permettono di eseguire determinate
>>query in una sola stored, oppure creare e richiamare da codice
>>diverse stored in base a quello che mi serve?
>A livello di prestazioni cambia molto poco, direi quasi niente.
ok perfetto

>Il fatto è che ci sono alcune domande che mi farei:
>- Tutte le chiamate in ogni caso tornano lo stesso resultset?
non sempre e cmq ci sono anche stored che chiamano salvataggi o eliminazione o aggiornamenti
>- Ha senso (o meglio porta vantaggi) mettere la logica di business
>sul db andando di fatto ad accoppiarsi alla base dati?
Ma io ho sempre pensato e fatto query di selezione, salvataggio, aggiornamento, creazione di tabelle temporanee in query ecc in stored sul db mentre la parte lato codice, gestita in classi, che richiama le stored appunto le scrivo solo in lato vb.
Se mi dici che conviene lasciare il database solo per le tabelle e relazioni, e scrivere tutto anche il codice sql su vb allora lo faccio non ci sono problemi. Unica domanda in sql ho una funzione scalare scritta che utilizzo, si può utilizzare lo stesso codice anche in vb? (penso di si cmq)
>- Se le chiamate non tornano ma fanno qualcosa (comandi di salvataggio
>ad esempio), ha senso portare la logica sul database?
>
>Secondo me devi capire bene dove ti servono quelle logiche, perchè
>farle a db mi sembra un po' eccessivo.
>Mi piace tenerlo snello per avere il pieno controllo di quello
>che il database fa come relazionale, non come layer di astrazione
>di logica.
>
>>grazie ciao
>di nulla!

>Alessandro Alpi | SQL Server MVP
>MCP|MCITP|MCTS|MCT
>
>http://blogs.dotnethell.it/suxstellino
>http://suxstellino.wordpress.com
>http://mvp.microsoft.com/en-us/mvp/Alessandro%20Alpi-4014222

Cirillo Fabio
www.trycontact.com
www.wondernet.biz
fabio@wondernet.biz
http://blogs.dotnethell.it/fabiocirillo/
http://wnetsoftware.blogspot.com

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: ven 20 feb 2015 - 14:26

>Ma io ho sempre pensato e fatto query di selezione, salvataggio,
>aggiornamento, creazione di tabelle temporanee in query ecc in
>stored sul db mentre la parte lato codice, gestita in classi,
>che richiama le stored appunto le scrivo solo in lato vb.
>Se mi dici che conviene lasciare il database solo per le tabelle
>e relazioni, e scrivere tutto anche il codice sql su vb allora
>lo faccio non ci sono problemi.
Non sto dicendo che va usato SOLO per tabelle e relazioni. Credo semplicemente che una stored procedure dovrebbe essere usata quando serve (ad esempio per query di lettura per cui ti serve tanto tuning) e non per definire logiche che sono proprie dell'applicazione. Perchè una stored procedure dovrebbe conoscere i comportamenti dell'applicazione? E quando vuoi scalare quelle logiche su più istanze della tua applicazione, come faresti? Non puoi, perchè la stored procedure centralizza il tutto sull'istanza SQL Server. Come al solito dipende dalla tua situazione reale. Tuttavia, le logiche che tendono ad accoppiarti al database, a mio avviso, dovrebbero essere spostate in un livello di astrazione per le logiche.

>Unica domanda in sql ho una funzione scalare scritta che utilizzo, si può utilizzare lo stesso codice
>anche in vb? (penso di si cmq)
Non scriverei SQL diretto nell'applicazione, e non userei Ado.net. Piuttosto mi farei aiutare da Entity Framework, che sta progressivamente migliorando. Comunque, sì, puoi chiamare una funzione se hai il controllo del t-sql che scrivi.

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/en-us/mvp/Alessandro%20Alpi-4014222

trinity Profilo | Guru

3.465 messaggi | Data Invio: ven 20 feb 2015 - 16:04

>>Ma io ho sempre pensato e fatto query di selezione, salvataggio,
>>aggiornamento, creazione di tabelle temporanee in query ecc in
>>stored sul db mentre la parte lato codice, gestita in classi,
>>che richiama le stored appunto le scrivo solo in lato vb.
>>Se mi dici che conviene lasciare il database solo per le tabelle
>>e relazioni, e scrivere tutto anche il codice sql su vb allora
>>lo faccio non ci sono problemi.
>Non sto dicendo che va usato SOLO per tabelle e relazioni. Credo
>semplicemente che una stored procedure dovrebbe essere usata
>quando serve (ad esempio per query di lettura per cui ti serve
>tanto tuning) e non per definire logiche che sono proprie dell'applicazione.
>Perchè una stored procedure dovrebbe conoscere i comportamenti
>dell'applicazione? E quando vuoi scalare quelle logiche su più
>istanze della tua applicazione, come faresti? Non puoi, perchè
>la stored procedure centralizza il tutto sull'istanza SQL Server.
>Come al solito dipende dalla tua situazione reale. Tuttavia,
>le logiche che tendono ad accoppiarti al database, a mio avviso,
>dovrebbero essere spostate in un livello di astrazione per le
>logiche.

Pertanto mi consigli di usare le stored per le query di lettura ossia query in cui mi serve selezionare parte dei dati da riportare su stampa o a video, invece le query di insert, update e delete eseguirle semplicemente nell'applicazione?
In aggiunta direi forse che ti riferisci anche al fatto che sarebbe meglio per esempio fare il controllo delle varie opzioni scelte dall'utente lato applicazione e non all'interno di una stored cioè per esempio sarebbe meglio creare 3 stored ben distinti che il loro dovere e gestire lato applicazione quale stored far partire e non inserire una if in un'unica stored e decidere tramite un parametro (flag) quale query avviare...

>>Unica domanda in sql ho una funzione scalare scritta che utilizzo, si può utilizzare lo stesso codice
>>anche in vb? (penso di si cmq)
>Non scriverei SQL diretto nell'applicazione, e non userei Ado.net.
>Piuttosto mi farei aiutare da Entity Framework, che sta progressivamente
>migliorando. Comunque, sì, puoi chiamare una funzione se hai
>il controllo del t-sql che scrivi.

ma io utilizzo System.Data.SqlClient, non va bene? entity framework non l'ho utilizzato perchè non sapevo come gestire in primis le stored e poi perchè alcune interrogazioni al database mi diventano più semplice scrivere in stored che in codice entity, ma se dici che entity sia meglio di sqlclient, cercherò di convertire tutto il progetto, tanto sta in fase di elaborazione

>
>Alessandro Alpi | SQL Server MVP
>MCP|MCITP|MCTS|MCT
>
>http://blogs.dotnethell.it/suxstellino
>http://suxstellino.wordpress.com
>http://mvp.microsoft.com/en-us/mvp/Alessandro%20Alpi-4014222
Cirillo Fabio
www.trycontact.com
www.wondernet.biz
fabio@wondernet.biz
http://blogs.dotnethell.it/fabiocirillo/
http://wnetsoftware.blogspot.com

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: ven 20 feb 2015 - 19:18

>Pertanto mi consigli di usare le stored per le query di lettura
>ossia query in cui mi serve selezionare parte dei dati da riportare
>su stampa o a video, invece le query di insert, update e delete
>eseguirle semplicemente nell'applicazione?
Sì, a meno che la tua applicazione non sia dbcentrica, caso nel quale va benissimo mettere una logica di business direttamente nel database.

>In aggiunta direi forse che ti riferisci anche al fatto che sarebbe
>meglio per esempio fare il controllo delle varie opzioni scelte
>dall'utente lato applicazione e non all'interno di una stored
>cioè per esempio sarebbe meglio creare 3 stored ben distinti
>che il loro dovere e gestire lato applicazione quale stored far
>partire e non inserire una if in un'unica stored e decidere tramite
>un parametro (flag) quale query avviare...
Sì, perchè non è leggibile e non è modulare. Riutilizzo del codice pari a zero (o circa) se vuoi lanciare SOLO un'operazione separatamente.

>ma io utilizzo System.Data.SqlClient, non va bene? entity framework
>non l'ho utilizzato perchè non sapevo come gestire in primis
>le stored e poi perchè alcune interrogazioni al database mi diventano
>più semplice scrivere in stored che in codice entity, ma se dici
>che entity sia meglio di sqlclient, cercherò di convertire tutto
>il progetto, tanto sta in fase di elaborazione
sqlclient è il namespace che usi per lanciare le query tramite ado.net. Va bene, ma devi stare attento ad usarlo bene, evitando SQL Injection e sapendo a priori il modello che hai "dietro le quinte".
Magari cerca di smettere di usare il System.Data per quanto riguarda DataSet e DataTable, preferisci l'approccio POCO model.

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/en-us/mvp/Alessandro%20Alpi-4014222

trinity Profilo | Guru

3.465 messaggi | Data Invio: ven 20 feb 2015 - 19:31

>>Pertanto mi consigli di usare le stored per le query di lettura
>>ossia query in cui mi serve selezionare parte dei dati da riportare
>>su stampa o a video, invece le query di insert, update e delete
>>eseguirle semplicemente nell'applicazione?
>Sì, a meno che la tua applicazione non sia dbcentrica, caso nel
>quale va benissimo mettere una logica di business direttamente
>nel database.

calcola un unico database su cui accedono n utenti, comunque farò come mi ha consigliato lascio sul db solo le query di selezione

>>In aggiunta direi forse che ti riferisci anche al fatto che sarebbe
>>meglio per esempio fare il controllo delle varie opzioni scelte
>>dall'utente lato applicazione e non all'interno di una stored
>>cioè per esempio sarebbe meglio creare 3 stored ben distinti
>>che il loro dovere e gestire lato applicazione quale stored far
>>partire e non inserire una if in un'unica stored e decidere tramite
>>un parametro (flag) quale query avviare...
>Sì, perchè non è leggibile e non è modulare. Riutilizzo del codice
>pari a zero (o circa) se vuoi lanciare SOLO un'operazione separatamente.

pertanto adotto la soluzione di stored separate e richiamate direttamente dall'applicazione e su questa eseguo controllo di quale stored avviare

>>ma io utilizzo System.Data.SqlClient, non va bene? entity framework
>>non l'ho utilizzato perchè non sapevo come gestire in primis
>>le stored e poi perchè alcune interrogazioni al database mi diventano
>>più semplice scrivere in stored che in codice entity, ma se dici
>>che entity sia meglio di sqlclient, cercherò di convertire tutto
>>il progetto, tanto sta in fase di elaborazione
>sqlclient è il namespace che usi per lanciare le query tramite
>ado.net. Va bene, ma devi stare attento ad usarlo bene, evitando
>SQL Injection e sapendo a priori il modello che hai "dietro le
>quinte".
>Magari cerca di smettere di usare il System.Data per quanto riguarda
>DataSet e DataTable, preferisci l'approccio POCO model.

non uso dataset qualche datatable per caricare in combobox dati, per le gridview passo al datasource direttamente una listoff collection.

comunque mi consigli di lasciare ado.net ed utilizzare entity framework...a pensare che all'inizio il progetto lo stavo scrivendo in entity solo che dopo non so come gestire le stored con l'entity e ho lasciato perdere.
Si possono gestire lo so ma gli esempi che avevo visto erano un casino.
Se mi consigli di usare entity, mi consigli di scrivere il codice tutto su applicazione oppure comunque usare ormai le stored che ho creato e pertanto ha un link che conosci dove fanno vedere esempi nei quali entity utilizza stored procedure?

ovviamente sfruttare entity framework significa utilizzare:

1) linq to entitis
2) SqlClient per Entity Framework
3) Provider EntityClient per Entity Framework

quali dei tre va bene?

inoltre leggendo questo su msdn:

EntityClient è un provider di dati utilizzato dalle applicazioni Entity Framework per accedere a dati descritti in un modello concettuale. Per informazioni sui modelli concettuali, vedere Modellazione e mapping. EntityClient utilizza altri provider di dati .NET Framework per accedere all'origine dati, ad esempio il provider di dati .NET Framework per SQL Server (SqlClient) in caso di accesso a un database SQL Server. Per informazioni sul provider SqlClient, vedere SqlClient per Entity Framework. Il provider EntityClient viene implementato nello spazio dei nomi System.Data.EntityClient.

sembra che sqlclient per entity framework sia migliore dato che si utilizza un db sql server o sblaglio?

Per concludere mi sono letto questo link: https://msdn.microsoft.com/it-it/library/dw70f090(v=vs.110).aspx

e su ADO.NET Entity Framework, si possono utilizzare sia LINQ to Entities che Provider di dati EntityClient (System.Data.EntityClient), tra i due quali ha meno svantaggi e più prestazioni utilizzando un db sql? Te quali useresti se nel caso sqlclient per entity non va bene?

inoltre aggiungo che ho appena finito di leggere questo articolo: https://msdn.microsoft.com/it-it/magazine/cc507640.aspx

e ho capito che ci sono per entity framework queste 3 tecniche:

Scrittura di query Entity SQL usando il provider EntityClient.
Scrittura di query Entity SQL usando Object Services.
Scrittura di query LINQ usando Object Services.

 Il codice sorgente non è stato renderizzato qui
perchè non c'è sufficiente spazio.
Clicca qui per visualizzarlo in una nuova finestra

pertanto se non ho capito male se io devo costruire query personalizzate in base alle mie esigenze, entityclient è la scelta migliore altrimenti si usa linq to entities

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: lun 23 feb 2015 - 10:09

>calcola un unico database su cui accedono n utenti, comunque
>farò come mi ha consigliato lascio sul db solo le query di selezione
non traviare le mie parole.. una stored procedure ti dà la possibilità di aggregare logiche sul database. Personalmente ho deciso di lasciare solo certe letture complesse (che usano tabelle temporanee ad esempio) su stored procedure, ma è perchè ho certe logiche che voglio che stiano sul database. Non necessariamente di lettura. Dipende dalle logiche tue e da dove le vuoi.

>pertanto adotto la soluzione di stored separate e richiamate
>direttamente dall'applicazione e su questa eseguo controllo di
>quale stored avviare
Sì questo è più comodo secondo me e disaccoppi il database dall'applicazione

>non uso dataset qualche datatable per caricare in combobox dati,
>per le gridview passo al datasource direttamente una listoff
>collection.

>comunque mi consigli di lasciare ado.net ed utilizzare entity
>framework...a pensare che all'inizio il progetto lo stavo scrivendo
>in entity solo che dopo non so come gestire le stored con l'entity
>e ho lasciato perdere.
Ti consiglio di usare entity se devi usare SQL in stringa, di certo.
Ma se chiami stored procedure, usa pure ado.net.

>Si possono gestire lo so ma gli esempi che avevo visto erano un casino.
per le sp preferisci ado.net

>Se mi consigli di usare entity, mi consigli di scrivere il codice
>tutto su applicazione oppure comunque usare ormai le stored che
>ho creato e pertanto ha un link che conosci dove fanno vedere
>esempi nei quali entity utilizza stored procedure?
dipende, devi fare tu un'analisi. Non esiste una sola tecnologia da usare. Usa quello che è più comodo per te.

>ovviamente sfruttare entity framework significa utilizzare:
>1) linq to entitis
>2) SqlClient per Entity Framework
>3) Provider EntityClient per Entity Framework
>quali dei tre va bene?
puoi pensare per le query che scriveresti in SQL diretto (tipo le operazioni di aggiornamento dirette, gli inserimenti, le eventuali cancellazioni, ecc) di usare Entity Framework con un database esistente.
linq to entities è semplicemente l'insieme di librerie che si connettono agli oggetti di entity framework per scrivere, appunto linq. Quindi, se ti serve, ne avrai bisogno, ma dipende dalle chiamate che fai.

>sembra che sqlclient per entity framework sia migliore dato che
>si utilizza un db sql server o sblaglio?
Migliore no, è una possibilità di gestire a codice il tuo data model. Si tratta di un namespace estremamente comodo.

>e su ADO.NET Entity Framework, si possono utilizzare sia LINQ
>to Entities che Provider di dati EntityClient (System.Data.EntityClient),
>tra i due quali ha meno svantaggi e più prestazioni utilizzando
>un db sql? Te quali useresti se nel caso sqlclient per entity
>non va bene?
Io userei Entity Framework con il tuo database esistente, andando a scrivere in maniera più semplice (via codice) le query e poi chiamerei stored procedure con ado.net.

>pertanto se non ho capito male se io devo costruire query personalizzate
>in base alle mie esigenze, entityclient è la scelta migliore
>altrimenti si usa linq to entities
Noi utilizziamo EF + linq.

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/en-us/mvp/Alessandro%20Alpi-4014222

trinity Profilo | Guru

3.465 messaggi | Data Invio: lun 23 feb 2015 - 10:39

Prima di tutto grazie mille del tempo che mi stai dedicando

>>calcola un unico database su cui accedono n utenti, comunque
>>farò come mi ha consigliato lascio sul db solo le query di selezione
>non traviare le mie parole.. una stored procedure ti dà la possibilità
>di aggregare logiche sul database. Personalmente ho deciso di
>lasciare solo certe letture complesse (che usano tabelle temporanee
>ad esempio) su stored procedure, ma è perchè ho certe logiche
>che voglio che stiano sul database. Non necessariamente di lettura.
>Dipende dalle logiche tue e da dove le vuoi.
>
>>pertanto adotto la soluzione di stored separate e richiamate
>>direttamente dall'applicazione e su questa eseguo controllo di
>>quale stored avviare
>Sì questo è più comodo secondo me e disaccoppi il database dall'applicazione
>
>>non uso dataset qualche datatable per caricare in combobox dati,
>>per le gridview passo al datasource direttamente una listoff
>>collection.
>
>>comunque mi consigli di lasciare ado.net ed utilizzare entity
>>framework...a pensare che all'inizio il progetto lo stavo scrivendo
>>in entity solo che dopo non so come gestire le stored con l'entity
>>e ho lasciato perdere.
>Ti consiglio di usare entity se devi usare SQL in stringa, di
>certo.
>Ma se chiami stored procedure, usa pure ado.net.
>
>>Si possono gestire lo so ma gli esempi che avevo visto erano un casino.
>per le sp preferisci ado.net
>
>>Se mi consigli di usare entity, mi consigli di scrivere il codice
>>tutto su applicazione oppure comunque usare ormai le stored che
>>ho creato e pertanto ha un link che conosci dove fanno vedere
>>esempi nei quali entity utilizza stored procedure?
>dipende, devi fare tu un'analisi. Non esiste una sola tecnologia
>da usare. Usa quello che è più comodo per te.
>
>>ovviamente sfruttare entity framework significa utilizzare:
>>1) linq to entitis
>>2) SqlClient per Entity Framework
>>3) Provider EntityClient per Entity Framework
>>quali dei tre va bene?
>puoi pensare per le query che scriveresti in SQL diretto (tipo
>le operazioni di aggiornamento dirette, gli inserimenti, le eventuali
>cancellazioni, ecc) di usare Entity Framework con un database
>esistente.
>linq to entities è semplicemente l'insieme di librerie che si
>connettono agli oggetti di entity framework per scrivere, appunto
>linq. Quindi, se ti serve, ne avrai bisogno, ma dipende dalle
>chiamate che fai.
>
>>sembra che sqlclient per entity framework sia migliore dato che
>>si utilizza un db sql server o sblaglio?
>Migliore no, è una possibilità di gestire a codice il tuo data
>model. Si tratta di un namespace estremamente comodo.
>
>>e su ADO.NET Entity Framework, si possono utilizzare sia LINQ
>>to Entities che Provider di dati EntityClient (System.Data.EntityClient),
>>tra i due quali ha meno svantaggi e più prestazioni utilizzando
>>un db sql? Te quali useresti se nel caso sqlclient per entity
>>non va bene?
>Io userei Entity Framework con il tuo database esistente, andando
>a scrivere in maniera più semplice (via codice) le query e poi
>chiamerei stored procedure con ado.net.

Qui mi sono un attimo perso ossia adesso ho rifatto un progetto nuovo ed installato ef 6.1.2 come primo step devo fare la connessione pertanto,
fatta in questo modo:

576x637 75Kb

come origine dati devo sempre scegliere Microsoft Sql Server come da figura

713x656 112Kb

e importo solo le tabelle e non le stored.

La cosa dove mi perdo è:
1) perchè mi consigli di utilizzare Ef e poi richiamare le stored con ado.net?
2) la connessione al database verrebbe fatta con Ef?
3) quindi poi come namespace dovrei importare nella pagine sia data.sqlclient che data.entity (giusto?)
4) come se il punto 3 è giusto come io con ado.net dovrei andare a richiamare quelle stored nelle quali utilizzo tabelle temporanee o funzion scalari come query create e personalizzate ad hoc per la mia situazione, mentre altre query di selezione ,inserimento,aggiornamento e eliminazione potrei scriverle nel codice dell'applicazione attraverso linq, giusto?
5) ma se utilizzo Ef per scrivere query non è meglio anche usare ef per richiamare le stored?

>>pertanto se non ho capito male se io devo costruire query personalizzate
>>in base alle mie esigenze, entityclient è la scelta migliore
>>altrimenti si usa linq to entities
>Noi utilizziamo EF + linq.
>
>Alessandro Alpi | SQL Server MVP
>MCP|MCITP|MCTS|MCT
Ciao
>http://blogs.dotnethell.it/suxstellino
>http://suxstellino.wordpress.com
>http://mvp.microsoft.com/en-us/mvp/Alessandro%20Alpi-4014222

Cirillo Fabio
www.trycontact.com
www.wondernet.biz
fabio@wondernet.biz
http://blogs.dotnethell.it/fabiocirillo/
http://wnetsoftware.blogspot.com

trinity Profilo | Guru

3.465 messaggi | Data Invio: mar 24 feb 2015 - 18:01

Ale quando parlavi qualche post fa di applicazione dbcentrica cosa volevi intendere? Nel senso il mio caso dove ho un server in cui vi un unico database e poi tanti client da remoto accedono su questo unico database è questo il caso di cui parli e per il quale a questo punto scrivere tutto su database ossia le stored va bene? Oppure no?
Comunque se ho capito ed è giusto quello che ho detto ora, per una applicazione web mi conviene scrivere la parte businness direttamente sul database o come parlavamo nei post precedenti ci scrivo solo le query di selezione mentre le insert,update e delete le scrivo direttamente nella pagina web lato code behind

Cirillo Fabio
www.trycontact.com
www.wondernet.biz
fabio@wondernet.biz
http://blogs.dotnethell.it/fabiocirillo/
http://wnetsoftware.blogspot.com

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mer 25 feb 2015 - 09:46

>Ale quando parlavi qualche post fa di applicazione dbcentrica
>cosa volevi intendere? Nel senso il mio caso dove ho un server
>in cui vi un unico database e poi tanti client da remoto accedono
>su questo unico database è questo il caso di cui parli e per
>il quale a questo punto scrivere tutto su database ossia le stored
>va bene? Oppure no?
quella che descrivi tu è un'applicazione single application. Un'applicazione, un database legato ad essa.
dbcentrica significa, che usa il database anche come livello applicativo, ossia, un repository dove metto anche logiche e programmazione.
Se ci pensi, un database con sole stored procedure che alimenta un'interfaccia di una riga di comando o una form semplice che non fa nulla se non interagire coi dati, è un'applicazione dbcentrica.

>Comunque se ho capito ed è giusto quello che ho detto ora, per
>una applicazione web mi conviene scrivere la parte businness
>direttamente sul database o come parlavamo nei post precedenti
>ci scrivo solo le query di selezione mentre le insert,update
>e delete le scrivo direttamente nella pagina web lato code behind
no no.. per logica di business intendo le decisioni, le condizioni, tutto quanto realizzi lo sviluppo dei requisiti.
la logica di business, a meno che l'app non sia dbcentrica, non dovrebbe essere scritta su database, anzi!
Il database dovrebbe essere la risorsa più preziosa a causa della persistenza dei dati, e dovrebbe avere praticamente solo quelli.
I livelli di astrazione successivi (possono essere anche tanti) servono per raggiungere dei requisiti che sono dati dal tuo design.
Ad esempio, in alcune realtà che ho seguito, vi è la necessità di rilasciare a moduli separati, quindi, per forza di cose, le logiche di business sono state isolate logicamente, in modo da poter toccare solo quanto basta per rilasciare il modulo.
Altrimenti, se metti le logiche e se scrivi codice tutto in un punto, dovrai rilasciare sempre tutto. Il che non è sempre corretto, dipende dalla tua situazione reale.
Allo stesso modo, le logiche scritte nell'applicazione sono poi legate all'applicazione. Quindi se gli stessi comportamenti poi li devi dare fuori usando, ad esempio, un'API verso l'esterno, sei costretto a spostare i comportamenti (che sono logiche di business) dall'app ad un livello in cui orchestri il tutto, oppure a replicare le stesse logiche sia nell'app (ad esempio che hai nel code behind) sia nella parte di API. Dipende sempre dai tuoi requisiti.
Visto che tu hai un website ed un server con su un database, il mio consiglio è di tenere il modello dati sul database server e solo quello.
Le query che necessitano gestione particolare (con tabelle temporanee ad esempio o variabili da gestire sul db) per le quali è necessario che la logica di business stia su db, possono essere tranquillamente stored procedure. Mentre per le altre puoi usare quello che trovi più comodo, ORM, ado.net, framework come simple.data. E non c'è una regola. E' una scelta che sta all'architetto dell'applicazione.
In generale, se fossi in te, creerei almeno un livello di business in cui mettere tutte le logiche di gestione, separate logicamente (anche più classi), disaccoppiando totalmente l'interfaccia (grafica o meno).
Cerca di fare in modo che "chi non deve sapere non sappia" (es. Perchè mai l'interfaccia dovrebbe conoscere un flag che discrimina logiche se il flag non va ne cambiato nè mostrato?).
Ho notato che cerchi molte regole fisse. Ma non ci sono. Le risposte purtroppo vertono sul concetto di "dipende".
A mio avviso dovresti provare ad approfondire alcuni principi della programmazione che ti consentono di disegnare l'architettura..
Come ad esempio i principi SOLID.
Ma qui non apro altre voragini

1) perchè mi consigli di utilizzare Ef e poi richiamare le stored con ado.net?
Forse perchè lo stai già usando. Non è che se hai già una tecnologia devi buttarla via

2) la connessione al database verrebbe fatta con Ef?
ogni tecnologia si connetterà a modo suo, cerca di usare i file di config e sei a posto

3) quindi poi come namespace dovrei importare nella pagine sia data.sqlclient che data.entity (giusto?)
dipende dall'utilizzo che ne fai, dipende quanti progetti hai, dipende da come vuoi impostare tu

4) come se il punto 3 è giusto come io con ado.net dovrei andare a richiamare quelle stored nelle quali utilizzo tabelle temporanee o funzion scalari come query create e personalizzate ad hoc per la mia situazione, mentre altre query di selezione ,inserimento,aggiornamento e eliminazione potrei scriverle nel codice dell'applicazione attraverso linq, giusto?
come meglio credi tu, hai assoluta libertà

5) ma se utilizzo Ef per scrivere query non è meglio anche usare ef per richiamare le stored?
scegli tu, io ti ho proposto alternative e vie.. poi segui tu quella che fa al caso tuo. Cerca anche documentazione su internet per capire chi ha affrontato le tue problematiche.

Non esistono regole fisse.
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/en-us/mvp/Alessandro%20Alpi-4014222

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !