ado.net модел
3 отговора
174 прегледа
ado.net модел
Не мога да разбера, защо адо.нет е направено така, че е невъзможно да се пише независимо от дата провайдера. Искам да ползвам DataReader (OleDbDаtaReader) и имам метод в дата-модула, който връща ОleDbDataReader. Ako реша да сменям провайдера на и ОлеДб не ми върши работа навсякаде, в клиентския код OleDbDataReader, трябва да се смени с (примерно) MySqlDataReader. 
Най-логично би било в клиенския код да може да се работи директно с интерфейса IDataReader и при смяна на базата данни да се променя само дата лейъра. Да, ама не става, защото OleDbDataReader i SqlDataReader и т.н. освен IDataReader имплементират и IDataRecord.
Из всички примери, които съм виждал никаде не се прави нещо подобно, стигам до извода, че просто не е възможно - Защо?
Не вярвам да не е било възможно да се направи така, или е нарочно или не са се сетили и в 2та случая ми спада мнението за дизайнерския екип на МС.
Най-логично би било в клиенския код да може да се работи директно с интерфейса IDataReader и при смяна на базата данни да се променя само дата лейъра. Да, ама не става, защото OleDbDataReader i SqlDataReader и т.н. освен IDataReader имплементират и IDataRecord.
Из всички примери, които съм виждал никаде не се прави нещо подобно, стигам до извода, че просто не е възможно - Защо?
Не вярвам да не е било възможно да се направи така, или е нарочно или не са се сетили и в 2та случая ми спада мнението за дизайнерския екип на МС.
Re: ado.net модел
Не мисля че дизайнерския екип на Майкрософт ще се впечатлят особено от твойто мнение, тъй като доколкото мога да заключа от подхода ти, не си ти човека който може да прецени доколко е добър дизайна на адо.нет.
Значи, OleDbDataReader и SqlDataReader са typed accessors, което значи че се знае какъв точно тип данни лежат отдолу, и чрез къстъм имплементация се оптимизира достъпа.
Картинката е следната:
ado.net -> oledb consumer -> oledb provider
идеята на адо (не само на адо.нет) е създаване на допълнителен слой между клиента и базата данни чрез лесен интерфейс от класове, така че като смениш дейта сорса да не се налага да пренапишеш дейта лейара си. Значи, първо ти хем искаш да прескочиш АДО класовете и да използваш директно оле дб провайдер, хем искаш да си ги сменяш както ти е кеф. Е как да стане това? Ква е тази изолация на клиент и данни като клиента иска да работи директно с интерфейс на дейта провайдера?
Добър подход е дейта лейара да връща DataTable или DataSet. Така независимо какъв провайдер ползваш, той винаги ще дава на клиента ADO структура, а не OLEDB провайдер интерфейс.
Преди да съдиш някой че е направил нещо не добре или не логично, първо се замисли че този някой е сред най-гениалните хора на планетата, който разбират нещата по начин по който ние няма да ги разберем и след 100 години.
XM TurboCT .. where comfort meets power
Значи, OleDbDataReader и SqlDataReader са typed accessors, което значи че се знае какъв точно тип данни лежат отдолу, и чрез къстъм имплементация се оптимизира достъпа.
Картинката е следната:
ado.net -> oledb consumer -> oledb provider
идеята на адо (не само на адо.нет) е създаване на допълнителен слой между клиента и базата данни чрез лесен интерфейс от класове, така че като смениш дейта сорса да не се налага да пренапишеш дейта лейара си. Значи, първо ти хем искаш да прескочиш АДО класовете и да използваш директно оле дб провайдер, хем искаш да си ги сменяш както ти е кеф. Е как да стане това? Ква е тази изолация на клиент и данни като клиента иска да работи директно с интерфейс на дейта провайдера?
Добър подход е дейта лейара да връща DataTable или DataSet. Така независимо какъв провайдер ползваш, той винаги ще дава на клиента ADO структура, а не OLEDB провайдер интерфейс.
Преди да съдиш някой че е направил нещо не добре или не логично, първо се замисли че този някой е сред най-гениалните хора на планетата, който разбират нещата по начин по който ние няма да ги разберем и след 100 години.
XM TurboCT .. where comfort meets power
в отговор на шeф нa Coди Дeвня
#3
Re: ado.net модел
Определено не се мисля за по-умен от дизайнерите на Microsoft, дори неопитното ми око вижда, че нещата са доста пипнати и добре измислени.
Не искам да прескоча адо класовете, идеята с ползването на
XXXDataReader, вместо DataSet е на Microsoft, с обяснението че достъпа е по-бърз, защото е оптимизиран само за четене. Това дизайнерско решение не съм го измислил аз, зная че няма смисъл, а и не мога да откривам топлата вода, а е директно от Data Application Block.
Имам пред вид заменяемостта на класовете OleDbDataReader, SqlDataReader, MySqlDataReader и т.н. Номера, е че те имплементират не един, а няколко интерфейса. За да се избегне това или трябва както или както в PetShop да се напишат няколко версии на бизнес класовете за всеки провайдър, или ( моя идея) с интерфейс ICustomDataReader, който обединява функциалността на XXXDataReader-ite с няколко имплементации за всеки по отелни и factory, което връща съответната инстация.
Все тая, ако само това е проблема, малко или повече се касае за search i replace, така че не съм кой знае колко притеснен.
В крайна сметка явно xxxDataReader-ite просто не са предвидени за тази цел, както DataSet примерно, ползването им въпреки препоръките май създава повече проблеми, отколкото решава.
Не искам да прескоча адо класовете, идеята с ползването на
XXXDataReader, вместо DataSet е на Microsoft, с обяснението че достъпа е по-бърз, защото е оптимизиран само за четене. Това дизайнерско решение не съм го измислил аз, зная че няма смисъл, а и не мога да откривам топлата вода, а е директно от Data Application Block.
Имам пред вид заменяемостта на класовете OleDbDataReader, SqlDataReader, MySqlDataReader и т.н. Номера, е че те имплементират не един, а няколко интерфейса. За да се избегне това или трябва както или както в PetShop да се напишат няколко версии на бизнес класовете за всеки провайдър, или ( моя идея) с интерфейс ICustomDataReader, който обединява функциалността на XXXDataReader-ite с няколко имплементации за всеки по отелни и factory, което връща съответната инстация.
Все тая, ако само това е проблема, малко или повече се касае за search i replace, така че не съм кой знае колко притеснен.
В крайна сметка явно xxxDataReader-ite просто не са предвидени за тази цел, както DataSet примерно, ползването им въпреки препоръките май създава повече проблеми, отколкото решава.