Re: ADO.NET 2.0 - ResultSet concerns
From: Scott Allen (bitmask_at_[nospam)
Date: 04/11/04
- Next message: Cor Ligthert: "Re: DataReader Limitation?"
- Previous message: Scott Allen: "Re: Ado.Net provider with sources."
- In reply to: William Ryan eMVP: "ADO.NET 2.0 - ResultSet concerns"
- Next in thread: Cor Ligthert: "Re: ADO.NET 2.0 - ResultSet concerns"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 11 Apr 2004 01:19:25 -0400
William:
I wouldn't categorize the feature as a "retreat" on the disconnected
model either, and I'm always happy to see new features and
capabilities added to the framework.
That being said...
It has felt like an uphill batlle here to get people over the
connected mindset and the hill looks like it gets steeper. Hopefully
the code wizards in 2005 will be a big help and get people started in
the right direction with effective code. We may not be able to get
features removed (and really I would not want to) but I think a strong
community voice could take care of shoddy code generation.
Yukon also makes me edgy. Having the CLR around will be a blessing in
many scenarios but I'm sure there will be some solutions out there
cursed with lots of procedural gook in the DB and much the worse for
it.
-- Scott http://www.OdeToCode.com On Sun, 11 Apr 2004 00:33:22 -0400, "William Ryan eMVP" <bill@NoSp4m.devbuzz.com> wrote: >I considered posting this OT, but I think it's relevant nonetheless. I've >been trying to get familiarized with ADO.NET 2.0 for a while now, and I have >the newest version of VS 2005 which I'm referring to. As much as I like >what MS is doing, I'm concerned it's going to be VERY Problematic. (I know, >that alone shouldn't impede progress and making omelettes requires a few >broken eggs and all that stuff but I'm wondering what the deal is). > >Read through this NG and you'll see many many of the same recurring >problems. Nothing different hear from other NG's. However, I think ADO.NET >was such a conceptual shift from ADO that a lot of people (A LOT) are >seriously lacking in their understanding of the how's/why's and >implementation of it. I'm not in any way besmirching any such >individuals..my learning curve was far from perfect and I certainly made a >lot of the mistakes I'm referring to...but ADO.NET is the most radical shift >in paradigms in the whole .NET framework vs. Old School. > >In comes the ResultSet. I like it quite a bit and I think it's a move >forward. With that said, I also think it's a disaster waiting to happen. >Why? > >- ADO.NET is billed as a 'disconnected' methodology. In fact, it is for >the most part. Unless you use a DataReader or Command.Executexxx methods. >No biggy there, but a LOT of people still have trouble distinguishing when >where to use the two. How many data access layers have we all seen where >people are trying to pass a DataReader through layers or threads thinking >it's not 'safe' to do? Threading is a little more obvious, but if the DAAB >passes datasets through layers via ExecuteDataset, it's not surprising that >many newbies think the same should work with DataReaders. > >So, we have Disconnected ADO.NET and Connected ADO.NET with a pretty clear >distinction (except for databinding in ASP.NET Datagrid which allows >executeReader but that's another issue). > >So the golden rule is Open your connection Only when you need to and close >it ASAP. Very easy concept by and large, but not necesssarily intuitive. >There are tons of posts where people want to 'leave a connection open' >through an entire user session for performance reasons. There are also tons >of posts where people want to use only one connection. > >Where does the resultset fit into this? I can go on and on about the >distinction between it and a datareader, I can go on and on about server >side cursors and the underlying architecture which will allow you to go >wherever you want in your results. > >But how do I explain in a concise and "correct" way when the newbies start >asking.... "When should I use a xxxDataReader and a xxxResultSet?" >And tell me that Disconnected methodology isn't going to be widely abandoned >by 1) newbies 2) former ADO users 3) people who still don't like dealing >with disconnected nuances? > >If it's updateable....everyone is going to use it as a magic bullet.."Gee >it's faster, easier to use and the only tradeoff is keeping a connection >open, heck I wanted to do that anyway". A datareader would have to be an >order of magnitude faster to make it more desirable for many folks. Then >throw in that it has a similar syntax to ado (NextResult, ReadFirst, >ReadLast etc) with similar functionality and basically I see one big ADO >Reborn. > >So in a nutshell, I think it's cool and has many virtues. I also think that >after a 3 year push to getting people to embrace "Disconnected" Methodology, >it's going to be a step backward. Some have went so far as calling it MS's >retreat on the disconnected model...I wouldn't go that far, but it's a more >than fair assertion. > >Any ideas? > > >Cordially, > >W.G. Ryan MVP >Windows - Embedded >http://www.msmvps.com/WilliamRyan/ >dotnetguru at co > >mcast dot net >wgryan at mvps dot org >bill at devbuzz dot com >www.devbuzz.com >www.knowdotnet.com >
- Next message: Cor Ligthert: "Re: DataReader Limitation?"
- Previous message: Scott Allen: "Re: Ado.Net provider with sources."
- In reply to: William Ryan eMVP: "ADO.NET 2.0 - ResultSet concerns"
- Next in thread: Cor Ligthert: "Re: ADO.NET 2.0 - ResultSet concerns"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
