"It certainly can't be my fault"

Published Thu, Sep 23 2004 1:55 | William

I guess I'm being a little fussy, but one thing that is really starting to get old is people in newsgroups that bitch about technological limitations of things that they don't understand.  Recently I read a post in a .NEt group where a guy pretty much lights into ADO.NET as pure hype.  The post starts out:

<<After plowing through the pages and pages of fancy disconnected
relational blah blah, I find myself wanting to do something so simple
- that you wouldn't think twice about it in SQL.  But in ADO.NET it
appears to be impossible - without resorting to hand coding all of it.
 The more things change, the more they stay the same.>>

So from the sounds of this, you would think that this post has to do with a limitation in ADO.NET right?  Well, shortly after the complaints we find out what his real problem is:

<<I have setup a Typed Dataset complete with relations, foreign keys and
all that jazz.

I have a GUI upon which is places two databound controls.  When the
user selects a Security, I would like to display the list of availible
Exchanges for that Security.

So far, I don't see one good way of utilizing the relations in place
for doing that.

DataTable.Select does what?  Return an array of DataRow.  What the
hell can I do with an array of DataRow in regards to a databound
control?

DataView.RowFilter takes a string expression that appears to allow a
relation to a Child - BUT ONLY if that child represents a single value
- otherwise you have to use an aggregate function - what the hell good is that.

SELECT Exchange.Description
  FROM Exchange, Security, ExchSec
 WHERE Exchange.ExchId = ExchSec.ExchId
   AND Security.SecId = ExchSec.SecId
   AND Security.SecId = "3"

SQL 101.

>>

Now, I'm not parsing words here, really, but what in the hell does this have to do with ADO.NET?  How is any of this possible a shortcoming of the DataSet he's using or the disconnected model?  If anything this is a shortcoming in DataBinding, not in ADO.NET.  Implementing the exact same scenario under old school ADO 2.x would somehow be easier?  The fact you can write a SQL Query to do this 'easily' means absolutely nothing.  (And back when i was in 101 - that exact query would have gotten me a good lecture from good old Dr. Jarman - but that's a whole different issue).

What I'm saying in a roundabout way is that they guy has a legitimate issue here.  Binding many-to-many relationships isn't all that fun but it's certainly doable.  But what baseline is  he comparing ADO.NET to?  SQL?  The Grid in Query Analzyer or Sql Plus?  Although they all display data they are certainly used in different regards.  But what bugs me is hearing people say somethign sucks or is lame just because they don't understand it.  I've heard at least 200 of these types of comments about ADO.NET, and probably 3 times that for the Compact Framework.  “Hey, you mean the Compact Framework doesn't support Remoting?  What kind of lame a33 crap is it anyway?“  People have every right in the world to state such opinions but it gets a little annoying - at least withhold judgement until you know what you're talking about.  Now every time I say this someone says something like “Well, do you have to have sex with a man to know that you're straight?  Do you have to shoot up heroin to know it's bad for you?  Do you have to actually sit next to Michael Moore to know that he smells like a33?“  To all of which I say No, no and no.  However knowing that you're straight isn't the same as saying that being Gay sucks [probably a bad choice of words].  You can just take one look at Courtney Love and know Heroin is bad for you and hell, you can almost smell the sweat and sausage burps coming from  Micheal Moore just watching him on TV.

Like any other technology, there's plenty to complain about in ADO.NET (although there's a lot less to complain about than any other data access technology I know), the Compact Framework, Fill In the Blank________________.  But running around bitching about something just because you haven't learned it yet (NOTE: lots of things are a little difficult when you're first learning them - that's why they call it a learning curve) , especially bitching about stuff that you're factually incorrect on, serves no purpose whatsoever, other than giving insomniatic bloggers something to do when Coast To Coast AM doesn't have anything good on.

Maybe the reason it 'sucks' so bad is because I'm using it incorrectly?  Nah, it COULDN'T Be my fault”  And <gasp>, although I answered the dudes question and asked a few follow up questions so I could help him out a little more, still no reply yet.

Filed under:

Comments

# William said on September 24, 2004 3:55 PM:

Currently my only introduction to ADO is using ADO 2.7 on SalesLogix. As far as straight ADO goes, I can't possibly live without it. Trying to do the equivalent in both SQL and Oracle would be a nightmare yet this "framework" (if you can call it that) allows for you to develop in one language (ADO) but have an end result in any backend database technology you can think of.

ADO.NET? ADO.NET 2.0? Lightyears ahead of normal ADO and I've barely even tried getting into it. I know without a shadow of a doubt its vastly better than normal ADO and I don't have to actually look at documentation or the specs to prove it. Since I have no projects that use ADO.NET yet, I'll be left in the dark about using that for a little while but I'm anxiously awaiting the day I get to be proficient in that.

I guess though in his defence if you are working with SQL only you can pretty much figure out how to get things working relatively easy. ADO makes it 100 times more easier to do the repetitive (read: boring) work involved in databases. Give him a couple of years and he might see the light, or it'll be beaten into him.

# William said on September 25, 2004 4:51 PM:

Jeremy:

I've paid my dues in ADO as well and like many things about it. But there are issues like losing your database connection that cause many apps to freeze up unless the programmers were meticulous in programming around it, that just aren't issues or if they are, are small ones in ADO.NET. I absolutely understand your point and the port to ADO.NET isn't feasible in many scenarios b/c of time or resources.

But, and I guess this was my main gripe - this is a Windows Forms issue. Binding doesn't behave the same in ASP.NET for instance although it's similar. The whole issue here that he was complaining about is really related to the behavior of bound controls and in such a way that only in the Winforms environment or similar one can this stuff even be possible. What I'm getting at is that I consider myself fairly decent at ADO.NET and do a heck of a lot with it. Much of the time I do little or nothing with Winforms. I've built a lot of back end processing recently that doesn't have any UI elements at all - totally ADO.NET & MSMQ. Now at some point some UI tool is driving this stuff but the involvement is really irrelevant to the processing other than to have a user confirm that they want to start or stop something. So none of this is really a shortcoming of ADO.NET - it's exclusively a Winforms issue. If you still have connected data objects (which you do if you're using hte datareader for instance), not one thing would change in this guy's scenario from the perspective of what's giving him problems.

To his credit, he acknowledged (after I made the poitn to him) that it wasn't an ADO.NET issue - but it's just kind of annoying to see something I use every day and am very fond of denigrated becuase of people that don't understand it (what else is new, right? From what I hear, Galilleo's 'round world' concept was denigrated by a few folks). Why it bothers me is b/c I have had to deal with folks that heard this type of nonsense ("We dont' want to use disconnected objects because of Concurrency issues", "Disconnected datasets don't really fit in here so we don't want to use them. In order for out app to run the computer needs to be connected to the network so if we're connected already, why go through the COMPLEXITY of using disconnected datasets"). These are two examples of REAL stuff I've heard and aren't the most naive of them. Sure, this is a minority but each of these statements came from Management - Decision makers and they certainly didn't come to these opinions on their own [I happen to know this for a fact]. Each time, so lame a33 gave ADO.NET a try, couldn't get it to work, got scared and insecure because a round earth was just too much for them to handle and they run back, and IMHO LIED (whether intentionally or not it doesn't matter, statements that ignorant coming from a professional is worse than intentionally lying so i don't really draw a distinction) because they wanted to use what made them comfortable. So, you don't need a network connection to use ADO.NET? Well, only if you're connecting to a local datastore or creating it locally - but what the hell, How does the disconnected data get disconnected if it was never connected in the first place (barring local creation of it)? If you don't have a network connection, SQL Server sitting on your domain won't do any good anyway. This stuff was preposterous.

Anyway, I'm clearly babbling ;-). Thanks for the reply my friend.

Search

This Blog

Tags

Community

Archives

News

My other sites

Cool Stuff

Book Stuff

Security

ORM

Data Access

Funny Stuff

Compact Framework Stuff

Web Casts

My KnowledgeBase Articles

My MVP Profile

Design Patterns

Performance

Debugging

Remoting

My Fellow Authors

My Books

LINQ

Misc

Speech

Syndication

Email Notifications