Books on ADO.NET 2.0?
johnb41
found 2 books that are rated well:
- Pro ADO.NET 2.0 (Expert's Voice)
- Programming Microsoft ADO.NET 2.0 Applications: Advanced Topics
However, I am looking to learn about the "new" way of working w/
data... TableAdapter, BindingSource, etc. From the descriptions of the
books, it kind of seems like these topics are not covered well, or at
all.
So my question is, what is a good ADO.NET 2.0 book that covers
TableAdapters, BindingSources, etc.?
Thanks!
John
W.G. Ryan - MVP
As a co-author on Professional ADO.NET 2 Programming [
http://www.amazon.com/gp/product/0764584375/qid=1135969158/sr=8-2/ref=pd_bbs_2/104-1909398-4591944?n=507846&s=books&v=glance ]
, I would recommend our book. We don't go through TableAdapters and binding
in depth but we cover the subject pretty well (obviously I'm a bit biased).
However you mention Pro ADO.NET 2.0 as well. Sahil's book is superb in
every respect and even though it's the 'competition', I was glad to have
reviewed it on Amazon and give it a perfect rating. His does a great job on
everything and his binding examples are great. I'm not going to shamelessly
plug my own stuff but suffice to say I think you'll like it. Similarly,
Sahil's Pro ADO.NET 2.0 is a masterpiece that you will be completely
impressed with - I couldn't speak any better of it if I tried.
"johnb41" <jsbuc...@gmail.com> wrote in message
news:1135964912....@g47g2000cwa.googlegroups.com...
johnb41
After I posted the question, i had the idea of calling a local store to
see if it's in, and if so, checking out the book myself.
So after work i'll actually browse the Pro ADO.NET 2.0 book to see if
it covers what I need. While i'm there i'll check out your book also!
Thanks,
John
Cowboy (Gregory A. Beamer) - MVP
is a fine addition.
If you want more detail, including how to use new features of SQL Server
2005 (including, in most cases, SQL Server 2005 Express) the Wrox
Professional ADO.NET 2 book that Bill mentioned should fit the bill. I am
also a cowriter, so I have a bias. I will say, however, that it is fairly
heavy in SQL Server development (with some open source and Oracle bits, as
well), so the content is more real world if you are .NET and SQL Server.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
***************************
Think Outside the Box!
***************************
clintonG
<%= Clinton Gallagher
"Cowboy (Gregory A. Beamer) - MVP" <NoSpamM...@comcast.netNoSpamM> wrote
in message news:217A9C58-AEB6-4E69...@microsoft.com...
john smith
well worth buying IMHO.
"W.G. Ryan - MVP" <Willi...@nospam.gmail.com> wrote in message
news:uhazaOXD...@tk2msftngp13.phx.gbl...
Sahil Malik [MVP C#]
- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
__________________________________________________________
"john smith" <jo...@smith.com> wrote in message
news:uMITsFaD...@TK2MSFTNGP14.phx.gbl...
johnb41
Thanks for jumping in! I hate to hijack my own threat, but since you
joined the thread, i might as well ask you a question...
I browsed your book today in a book store. I see that techniques with
the TableAdapter is only covered in just a couple pages. The rest of
the book shows the traditional "classic" ado.net techniques.
The past couple days i've been fixated on the new TableAdapter and its
related objects. I was introduced to them via the videos from
learnvisualstudio.net, and the msdn documentation highly recommends to
use these new objects.
But your book justs mentions them briefly.
Can you explain why you chose to do so? I'm just so conflicted... I
don't know which direction to go, and hopefully you'll help!
Thanks,
John
Sahil Malik [MVP C#]
> Can you explain why you chose to do so?
I don't like TableAdapters :), I don't think they are suited well enough to
a production enterprise application.
Why?
- They suck eggs with System.Transactions (watch out for my coming article
in code-magazine on this).
- They donot have transactional support built into them, adding that on top
is painful
- They are very single table specific
- They are impossible to make work with multiple tables in hierarchcial
scenarios and concurrent environments reliably
- They have poor concurrency mangement options built into them
- Do they use generics? I don't think they do.
- They are unweildy to maintain as your db structure changes
- They are very structure specific, so you need multiple table adapters for
every single get/update scenario
- They have hardcoded queries in them (which don't even use StringBuilder
by the way), the generated code of strongly typed datasets is quite awful.
- If you need custom persistence logic, save this record and send me an
email on success - you're screwed with TableAdapters, it's going to be built
on top in a very inelegant way.
- Your DBA will hate you if subject them to the queries TableAdapters
generate by default
- and more
I have given enough attention to this topic as I felt it deserved in Chaps 3
and 6. But truthfully, I have clearly stated my opinions in chapter 3 that a
drag drop application is not what you want in any real application. So
TableAdapter isn't necessarily the "new way of doing things" - it is merely
the new demonstration Microsoft guys could give to wow the CIO of your
company. That is probably what MS uses to sell .NET LOL :). Now once you do
get .NET in, you probably want a hand architected/hand written ADO.NET
application for any serious task.
Now I'm a bit tickled to hear that MSDN docs highly recommend to use these.
Can you point me to specific articles so I can argue with the appropriate
folks? I don't like the default drag drop goo that is generated in .NET
2.0 - Datasets and TableAdapters both. And I want to argue and find out if
I'm talking out of my ar*se or do I really have a point. In some manner, I
wish to be able to give my honest feedback to Microsoft, so it would be
incredibly helpful if you could point me to specific MSDN articles that I
should bitch about :). Regards Learnvisualstudio.net videos - Well, some
folks buy into the MS koolaid and talk like MS marketing, I'm probably one
of them to some extent. And some folks try to bring forth the real deal -
here is what is good, here is what sucks. I haven't seen those videos so I
cant comment, but I've done videos for keystonelearning.com and over there I
mentioned TableAdapter a bit and said "WOW HOW COOL" and then showed the
code it generated and how bad that was and said "OH THIS SUCKS". and WTF do
I do now .. and then I show the real deal, how to actually use the objects
to do the right thing.
It's all a question of sifting chaff from the wheat man :)
> I'm just so conflicted... I
> don't know which direction to go, and hopefully you'll help!
Unless you are creating a single user app, non-production - drag drop get
over with and move on with life, TableAdapter may work for you and my book
tells you enough to get by with that. For anything serious and practical,
forget this Drag Drop goo. And trust me, in the base framework libraries,
ADO.NET 2.0 has **PLENTY** of new and good stuff.
- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
__________________________________________________________
"johnb41" <jsbuc...@gmail.com> wrote in message
news:1135999944.5...@g44g2000cwa.googlegroups.com...
Cor Ligthert [MVP]
To give you another opinion. I have only (good) looked at the newly
generated dataset/datatable approach. It is so much better than the old
strongly typed dataset that I am for the moment really impressed by it.
However, as you, I do not know enough in dept of it yet, to give you a real
good opinion. For what I have seen, I get the idea that it will replace in
many places the classic used AdoNet way of use.
As well gives the new methods in my idea now really a strong advantage in
getting and handling the data.
My main disadvantage against the old Strongly Typed DataSet was that it was
impossible to use, because you could not change one letter and become in
trouble because of the fact that the fetching of the data (in the component
or the form) was set apart from the data in the strongly typed dataset
class.
A small problem is that it is not so easy to describe in a book or in a
newsgroup, because the generated names are every time different (as they
should be).
Cor
mabl...@otismukinfus.com
<contactme...@nospam.com> wrote:
Now, Sahil, please tell us what you really thing about TableAdapters
;o)
I have your book and think it is very good. Thank you for writing it.
Otis
Sahil Malik [MVP C#]
- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
__________________________________________________________
<mabl...@otismukinfus.com> wrote in message
news:cr5dr15nt39isle59...@4ax.com...
johnb41
Thanks for the great reply! I'm actually happy about this because i'm
already fairly comfortable working w/ the established techniques.
When i get back to work Monday i'll find the link on MSDN for free
video tutorials, created by learnvisualstudio.net, which deal with the
tableadapter and related objects. Also i'll find the MSDN article that
recommends the "new" way rather than the "better" way. :)
I'll be sure to order your book before the weekend is over! :D
John
Sahil Malik [MVP C#]
you like the book.
- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
__________________________________________________________
"johnb41" <jsbuc...@gmail.com> wrote in message
news:1136094131.6...@g49g2000cwa.googlegroups.com...
William (Bill) Vaughn
your book as well.
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
"Sahil Malik [MVP C#]" <contactme...@nospam.com> wrote in message
news:%23KpLaaf...@TK2MSFTNGP15.phx.gbl...
William (Bill) Vaughn
are included in the www.LearnVisualStudio.NET content.
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
"johnb41" <jsbuc...@gmail.com> wrote in message
news:1136094131.6...@g49g2000cwa.googlegroups.com...
johnb41
http://www.learnvisualstudio.net/videos/sitemap.htm has all the
tutorials available. Go near the bottom of the page and you'll see the
tutorials for VB 2005 Express.
You actually need to subscribe to get access to ALL those videos, but
the author has recently partnered up w/ MS... so anyone can view them
(only VB 2005 Express videos) for free here:
http://msdn.microsoft.com/vstudio/express/vb/learning/default.aspx
John
Sahil Malik [MVP C#]
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'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
__________________________________________________________
"William (Bill) Vaughn" <billvaRe...@nwlink.com> wrote in message
news:uyQ2ME%23DGH...@TK2MSFTNGP15.phx.gbl...
Sahil Malik [MVP C#]
Okay I saw the videos, and I read your message on my blog.
Tell u what - I still maintain that TableAdapters is "one way" of doing
things. It's one of the new ways and in my opinion, what should be one of
the lesser preferred ways in most situations.
I still feel a handwritten app will turn out better. Though I am curious to
see that Change in DLINQ.
- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
__________________________________________________________
"johnb41" <jsbuc...@gmail.com> wrote in message
news:1136239213....@f14g2000cwb.googlegroups.com...
johnb41
Thanks for taking the time to check out the vids, etc. I do think that
the TableAdapter approach does allow for alot of low level hand coding
(for lots of control) as a couple of the videos show. But the most
control and power is had when coding w/ traditional dataset,
dataadapter, connection, etc. I'll stick with what you teach in your
book! :)
What's funny is the msdn docs would agree that this is easier to read:
myDataset.customer.AddCustomerRow(newrow)
vs.
myDataset.tables("Customer").Rows.Add(newrow)
For day's i've tried to stretch my head to be comfortable w/ the "new"
way, but i find it so much harder. I like the way that many things now
appear in the intellisense, where you normally would have to memorize,
but that's the only benefit that i saw in practice.
By the way, I ordered your book today on Amazon. I couldn't want to
start reading it, so i visited the Barnes & Noble after work to get a
head start. But the book they had a couple days earler was sold, and
they had no more. Looks like i'll have to wait a few days!
John
Sahil Malik [MVP C#]
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
__________________________________________________________
"johnb41" <jsbuc...@gmail.com> wrote in message
news:1136264685.3...@f14g2000cwb.googlegroups.com...
Cor Ligthert [MVP]
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
--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
johnb41
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
Great book though, make sure you buy it.
Vayse
"johnb41" <jsbuc...@gmail.com> wrote in message
news:1136303068.7...@g49g2000cwa.googlegroups.com...
Sahil Malik [MVP C#]
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" <va...@nospam.nospam> wrote in message
news:Oe31b4H...@tk2msftngp13.phx.gbl...
Sahil Malik [MVP C#]
- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
__________________________________________________________
"Frans Bouma [C# MVP]" <perseus.us...@xs4all.nl> wrote in message
news:xn0egsiu...@news.microsoft.com...
Vayse
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#]" <contactme...@nospam.com> wrote in message
news:e8cnUIIE...@TK2MSFTNGP11.phx.gbl...
Sahil Malik [MVP C#]
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
----------------------------------------------------------------------------
"Vayse" <va...@nospam.nospam> wrote in message
news:ua584ZVE...@TK2MSFTNGP15.phx.gbl...