Theory
ADO.NET નાં પાત્રો
ADO.NET પોતાનું કામ મુઠ્ઠીભર objects દ્વારા કરે છે, અને દરેકની ભૂમિકા સ્પષ્ટ છે. કોણ શું કરે છે એ એક વાર ખબર પડે, પછી code નાના નાટક જેવો વંચાય છે: જોડાવ, હુકમ કરો, વાંચો, કે ભરો.
આ પાઠ એ પાત્રોનાં નામ આપે છે, એટલે કે provider, Connection, Command, DataReader, DataAdapter અને CommandBuilder, અને બતાવે છે કે FestConnect નો data database અને તમારા code વચ્ચે ખસેડવા એ કઈ રીતે સાથે કામ કરે છે. ભૂમિકાઓ શીખી લો એટલે પછીનો code તરત જ સમજાશે.
At a glance
| Object | ભૂમિકા |
|---|---|
| Data provider | એક પ્રકારના database માટેનો classes નો સમૂહ (SQL Server માટે SqlClient, બીજાં માટે OleDb) |
| Connection | Connection string વાપરીને database સાથેની લાઇન ખોલે અને બંધ કરે છે |
| Command | SQL વિધાન (કે stored procedure) સાચવે છે અને એને ચલાવે છે |
| DataReader | Rows ને વહેતી પાછી લાવે છે, ફક્ત આગળ તરફ અને ફક્ત વાંચી શકાય એવી (connected model) |
| DataAdapter | Database અને DataSet વચ્ચે પુલ બાંધે છે: load કરવા Fill, સાચવવા Update |
| CommandBuilder | ફેરફારો સાચવવા DataAdapter ને જોઈતાં INSERT, UPDATE અને DELETE commands જાતે બનાવી આપે છે |
Theory
Providers: તમારા database માટેના સાચા classes
Data provider એટલે એક પ્રકારના database માટે લખાયેલો આ જ classes નો પરિવાર. SQL Server માટે તમે SqlClient provider વાપરો છો, જેનાં objects નાં નામ SqlConnection, SqlCommand, SqlDataReader, SqlDataAdapter છે. બીજાં databases માટે OleDb provider છે (OleDbConnection, અને એમ આગળ).
બધા providers માં ભૂમિકાઓ એકસરખી જ છે; ફક્ત આગળનો ઉપસર્ગ બદલાય છે. SqlClient સાથે એક વાર આ ઢબ શીખી લો એટલે provider બદલીને તમે કોઈ પણ ટેકો ધરાવતા database સાથે વાત કરી શકો. FestConnect SQL Server પર ચાલે છે, એટલે એ બધે SqlClient વાપરે છે.
Theory
એ બધાં કઈ રીતે સાથે કામ કરે છે
ઝડપી વાચન માટે (connected): Connection લાઇન ખોલે છે, Command તમારું SELECT લઈ જાય છે, અને ExecuteReader બોલાવવાથી DataReader મળે છે જેમાંથી તમે rows વહેતી વાંચો છો, પછી બંધ કરો છો.
Memory માંની નકલ માટે (disconnected): DataAdapter Command ને વીંટી લે છે, અને એની Fill method connection ખોલે છે, rows ને DataSet માં load કરે છે અને તમારા વતી connection બંધ કરી દે છે. પછીથી એની Update method ફેરફારો પાછા સાચવે છે, અને Update ને જોઈતાં INSERT, UPDATE તથા DELETE commands CommandBuilder બનાવી આપી શકે છે, જેથી તમારે એ હાથે લખવાં ન પડે.
Practical
બંને ઢબોની રૂપરેખા
// Connected: Connection -> Command -> DataReader
using (var conn = new SqlConnection(connectionString))
{
var cmd = new SqlCommand("SELECT Name FROM Events", conn);
conn.Open();
SqlDataReader reader = cmd.ExecuteReader(); // stream rows
while (reader.Read()) { /* use reader["Name"] */ }
} // connection closed automatically
// Disconnected: DataAdapter fills a DataSet, then closes
var adapter = new SqlDataAdapter("SELECT * FROM Events", connectionString);
var ds = new DataSet();
adapter.Fill(ds); // opens, loads into memory, closes for you
// work with ds in memory; adapter.Update(ds) saves changes backQuiz
ADO.NET માં તમારું SQL વિધાન સાચવવાનું અને એને database સામે ચલાવવાનું કામ કયા object નું છે?
- Connection, કારણ કે એ SQL ચલાવે છે
- Command, જે SQL વિધાન કે stored procedure સાચવે છે અને એને ચલાવે છે
- DataReader, કારણ કે એ SQL મોકલે છે
- CommandBuilder, કારણ કે એના નામમાં 'Command' આવે છે
Show the answer
Command, જે SQL વિધાન કે stored procedure સાચવે છે અને એને ચલાવે છે
Command object SQL વિધાન (કે stored procedure) સાચવે છે અને એને ચલાવે છે, એટલે કે SELECT માટે ExecuteReader થી, INSERT/UPDATE/DELETE માટે ExecuteNonQuery થી, કે એક જ કિંમત માટે ExecuteScalar થી. વિકલ્પ A ખોટો છે: Connection ફક્ત database સાથેની લાઇન ખોલે અને બંધ કરે છે; એ તમારું SQL લઈ જતું કે ચલાવતું નથી. વિકલ્પ C ખોટો છે: Command જે rows ઉપજાવે એ DataReader મેળવે છે અને વહેતી આપે છે; એ SQL મોકલતું નથી. વિકલ્પ D નામનો ફાંદો છે: CommandBuilder તમારી query ચલાવતું નથી, એ તો ફેરફારો સાચવવા DataAdapter ને જોઈતાં INSERT, UPDATE અને DELETE commands જાતે બનાવી આપે છે. દરેક object ની એક જ ભૂમિકા છે: Connection જોડે છે, Command હુકમ કરે છે, Reader વાંચે છે.
Think first
CommandBuilder ખરેખર કઈ મહેનતમાંથી બચાવે છે?
DataAdapter જાતે જ DataSet ને Fill કરી શકે છે. તો CommandBuilder શા માટે છે, અને એ કઈ રીતે સગવડભર્યું છે? વિચારીને પછી tap કરો.
Show the answer
DataAdapter ફક્ત SELECT થી વાંચી શકે છે, પણ ફેરફારો પાછા સાચવવા માટે એની Update method ને બીજા ત્રણ commands જોઈએ: નવી rows માટે INSERT, બદલાયેલી rows માટે UPDATE અને કાઢેલી rows માટે DELETE. દરેક column અને key બરાબર બેસાડીને એ ત્રણ SQL વિધાનો હાથે લખવાં કંટાળાજનક છે અને એમાં ભૂલ થવાની શક્યતા પણ ઘણી છે. CommandBuilder તમારા SELECT ને તપાસે છે અને એ INSERT, UPDATE તથા DELETE commands તમારા વતી જાતે બનાવી આપે છે, એટલે તમે એ લખ્યા વગર જ Update ચાલવા માંડે છે. સગવડ એ જ છે: એક જ table વાળા સાદા કિસ્સામાં તમે CommandBuilder જોડી દો એટલે adapter DataSet માંના ફેરફારો, ઉમેરાઓ અને કાઢી નાખવાનું સીધું database માં પાછું સાચવી શકે છે. સામે ભોગ એ કે એ ફક્ત સીધાસાદા કિસ્સા સંભાળે છે (એક table, key નક્કી થયેલી); ગૂંચવણભરી queries કે joins માટે commands તમારે જાતે લખવાં પડે, ઘણી વાર stored procedures તરીકે. એટલે CommandBuilder સામાન્ય સાદા કિસ્સા માટે સમય બચાવનારું છે, બધા માટેનું ઓજાર નહીં. કંટાળાજનક SQL એ લખી આપે છે જેથી તમારે લખવું ન પડે.
Summary
Key takeaways
- ADO.NET થોડાં પાત્રો દ્વારા કામ કરે છે: provider, Connection, Command, DataReader, DataAdapter, CommandBuilder.
- Data provider એટલે એક પ્રકારના database માટેનો classes નો પરિવાર: SQL Server માટે SqlClient, બીજાં માટે OleDb; ફક્ત ઉપસર્ગ બદલાય છે.
- Connection લાઇન ખોલે અને બંધ કરે છે (connection string દ્વારા); Command તમારું SQL સાચવે છે અને ચલાવે છે.
- Command ચલાવવાની રીતો: SELECT માટે ExecuteReader, INSERT/UPDATE/DELETE માટે ExecuteNonQuery, એક કિંમત માટે ExecuteScalar.
- Connected model માં DataReader rows વહેતી આપે છે; disconnected model માં DataAdapter નું Fill DataSet ભરે છે અને Update ફેરફારો સાચવે છે.
- સાદા ફેરફારો સાચવવા DataAdapter ને જોઈતાં INSERT, UPDATE અને DELETE commands CommandBuilder જાતે બનાવી આપે છે.
- યાદ રાખવાની કડી: Connection જોડે છે, Command હુકમ કરે છે, Reader વાંચે છે, Adapter ભરે છે, Builder કંટાળાજનક SQL લખે છે.