Books on ADO.NET 2.0?

[Sahil Malik [MVP C#]]

Hey John,

Easier to read doesn't necessarily mean it works better. That code snippet
below is rather simplistic. When you do get my book, read up the concurrency
and updating data issues in Chapters 9 and 10. There is no frickin' way
TableAdapters can make work with that.

Even in my book, Chapters 6 and 8, I agree the below is easier on eyes.
Strongly Typed Datasets have a FindByCustomerID(Int32) rather than
Find(object). In perspective of architecture (and I discuss this frequently
in my book and on my blog), I like to view systems as a combination of
connected and disconnected. (Assuming every system is a method of
manipulating data).

Disconnected portions are super important in any serious app - although a
100% disconnected or a 100% connected system is a reflection of bad design.

SO when we talk about Disconnected systems, you need something to store and
transport your disconnected data in. Here you have two choices -

a) Dumb data buckets - datasets and strongly typed datasets. or
b) Business objects - smart or otherwise

Business objects is a whole another topic and I like to refer to Rocky
Lhotka as the Guru on those. But when it comes to DataSets, they will get
you through 90% of the tasks you need, but in very specific situations, such
as saving hierarchical data - they fall sorely short of what you may need.

While I want to lean towards handwritten apps, it would also be wrong to
outright critcize TableAdapters into banishment/uselessness. Truthfully I
use them at times. This is even more true for DataSets. But it would be
sorely incorrect to say that "That is the new way of doing things, and
forget handwritten code". In certain specific situations you are *better
off* using strongly typed datasets over non strongly typed. It's all gray -
it depends on the situation, no black or white. But in MOST situations you
want a handwritten app. TableAdapters donot fit most real world requirements
IMO.

But I'll leave you with a practical instance of "Where you'd prefer a
strongly typed ds over a non strongly typed".

Say you have 2 columns - Price, Tax. And you want a third calculated column
TotalPrice = Price + Tax.

So if you had non strongly typed dataset - You would have to .. umm fill the
data, add a column then set the expression .. but that won't work. Because
it would add 1.05 and 0.25 as 1.050.25 (as strings). Why? Because it doesn't
know the data types. So now you can set the data type .. right? NOPE - you
need to set DataTypes *before* you fill the data. So you need to write code
to maintain data types, and then fill data - what a pain in the ar*se.
Especially because now when the structure changes, my programattical schema
declarations are all over my code - hard to trace. .. Man I wish there was
an XSD I could modify here . Compared with Strongly Typed Datasets - you
don't specify the schema, it comes with the schema at runtime. Ain't that
cool

So in very very isolated incidents, strongly typed ds may even be preferable
over non st-datasets. Ditto for TableAdapters, I'm sure in a specific
situation you may prefer to use them over other choices - but it would be an
exception.

I think my book will arm you with sufficient knowledge to make these
judgement calls as you go along architecting an app. Or hey if there are
questions I'm around , (as are many other smart individuals in this NG).

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
__________________________________________________________

 

[Cor Ligthert [MVP]]

Bill,

As you have probably seen am I busy to look for myself what the
DataAdapter/DataSet approach means for Middle Tier and DataLayers.

At the moment I am sceptic.

The DataSet/DataAdapter looks very nice in Window Forms applications. I am
in doubt because the different approach that there seems to be between the
WindowsForm and the ASPNET way if the dataadapter will not be a short living
child. (While if it was used in the same way in ASPNET (WebPage and
WebService) as in WindowsForms I think it would have been a great step
forwards.

However as you probably saw already I am just starting investigating it for
myself and did not see yet if I can using the ObjectDataSource in code could
reach that.

I thought that it was a good point to show you this because of your books,
so maybe can you investigate this as well deeper.

Cor

 

[Frans Bouma [C# MVP]]

Bill,

Well that depends on what context am I being quoted in

I'm somewhat worried about pissing the person who architected
TableAdapters in the first place. Given that it is a tall order
anyway, this was a tough job to begin with - but I do maintain that
it could have been done better.

I have the weird feeling it was the same guy/team who also cooked up
the data-adapter objects in visual interdev(il) which did great in
demos but sucked in real-life.

It's pure demo-ware: no-one will use it in an enterprise app, but it
works great on demos where visuality is key for success for the large
clueless crowd to go 'ohh aahhh'....


FB

I'm a bit curious about what you have up your sleeve before you quote
me . Y'know Kevlar Jacket 'n all.

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
__________________________________________________________




enough >> to a production enterprise application.

--

 

[Sahil Malik [MVP C#]]

I'm glad we agree.

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
__________________________________________________________

 

[johnb41]

Sahil,

Little confusion here... the "pain in the a*rse" coding is with
dataadapter/connection/dataset? Is that classic combo considered "non
strongly typed"? But the tableadapter/etc. method is "strongly typed"
and can be cool, but you get this at a price of less power and
flexibility?

I ask this because all the documentation i've read is that the
tableadapter/dataset IS strongly typed, and that's why it's so highly
recommended.

Or am i just hopelessly confused... and my only hope is to read your
book?!

John

 

[Vayse]

I've read the book, and I'm still a bit confused!
Great book though, make sure you buy it.
Vayse

 

[Sahil Malik [MVP C#]]

Thank you Vayse.

Okay there shouldn't be any confusion

The issue I face is, there is way too much to explain than I can type in
this message here, but it's all in my book.

Here is what I was talking about specifically -

In that specific scenario that I mentioned in my reply to John, strongly
typed datasets are better. (Expression columns with data types). See the
strong typing and compile time checking is only *one* of the benefits that
strongly typed datasets (STDs) offer. IMO it is a small advantage. Compile
time checking is good, but by far not the only thing you need. In fact in
certain instances strict compile time checking may work to your
disadvantage, because you are faced with the daunting task of keeping the
datasets up to date. Also, if a stored procedure could return different
table structures based on the inputs specified, what structure do you
conform with? . The "Compile Time Checking" is a very small advantage that
anyone can think of when viewing from 30,000 feet. It's not until when you
start writing some real applications that you realize where STDs truly suck
or not suck.

STDs biggest advantage is their ability to keep your data somewhat compliant
with the XSD you specified. So when specifying an expression to add two
columns, the STD knows that the data types are Int32 so it adds them, not
concatenates them (strings).

The advantages of strong column naming are .. well somewhat important, but
when subjected to real practical applications, STDs offer way more and much
more important advantages than simply "compile time checks". Here is another
good example where strongly typed datasets will make your life easier -
"Merging". Because there is a schema present, the merging will be somewhat
sensible.

Here is a good quote to remember -
The biggest issue with working with disconnected data, is "what do you do
with it when it needs to be put back into the db". The updates can get
really complicated, and all the folks who say "Abstract your BOs as much as
possible from the data structure", are setting themselves up for a lot of
pain .

STDs make that job somewhat easier. Not idiotproof, but just easier. Thats
the key - in certain instances it's still not idiot proof and in certain
instances you may still prefer to use a plain vanilla dataset.

But does this mean you should always use STDs? Heck no. Thats what I keep
reiterating in my book - it's never black and white in data access, there
are plenty of shades of gray, and you have to know enough working knowledge
to distinguish between the shades of gray so you can make the right
decisions. STDs have their own downsides.

Finally, what bugs me is the poor autogenerated code in STDs and
TableAdapters in general. I spoke earlier about TableAdapters and where they
fall short, but here is an instance where STDs fall short in .NET 2.0 -
http://codebetter.com/blogs/sahil.malik/archive/2005/12/26/135954.aspx

So extending out of the box behavior is problematic at best, only because
there is a hairy 12 legged bug in the code.

Sorry for the extremely long replies , I know you're busy, but I wanted to
do this topic justice as there is a lot more to it than can be typed out in
a little reply.

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx

 

[Vayse]

Sahil
Thanks for the properly explained reply, it was enlightening.
By confusion, I mean it doesn't really matter how many books you read, often
only experience will give one an idea of the correct path.
Especially when different books give conflicting information! I think one of
the best aspects of your book was that you do explain that there are shades
of gray.

Using the XSD drives me mad sometimes. For a start, at the early stages of
development, one often adds several new fields to each table. The wizard
often has problems with these fields. Also, changing the names of fields
already in the schema is also troublesome, with the schema usually
containing both the old and the new field name. Certain field names also
cause a problem. And yes, I have the latest version of everything.
I've found that using STDs with Access can be very slow. Stuff that flies
along with SQL Server, crawls in Access.

Nearly all online articles I've read are very pro STD. Likewise, I've been
to 3 Microsoft VS2005 events, and the main thing they push is the XSD and
the drag/drop data forms. As John mentions, most of the documentation also
recommends STD as the way to go. Fortunately I got your book, so I at least
have some light in the darkness!
( ok - thats the last free praise you get. To make my post balanced, I feel
I must point out that your picture on the back cover makes you look 12 years
old, and I originally thought that the guy in the suit on page xv was
someone else!)
My own opinion is that STD is a great idea, but you have to be aware of its
limitations and the alternatives.

I switched to .Net around 6 months ago. At the time I had read a MSDN
article that said ADO.Net had only one way of doing everything, so there was
much greater uniformity of code amongst programmers.
Now that I've used it, I can only say "Hah!"
I'm not bashing dotnet though, its a great product and I've glad I switched.

Btw, on the 'many ways of doing' , I'd appreciate your input on my other
thread - "Updating - let me count the ways"

Thanks
Vayse

 

[Sahil Malik [MVP C#]]

Hey man that picture is about 2 years old (actually both of the pictures are
about 2 years old).
Y'know maybe I could pass off as a 12 year old. Atleast that way I'd get
laid a bit more huh? , hey I gotta use those boyish charms until I can
huh?
Lemme look @ your other thread.

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx