Re: Need some advice on ADO .NET
From: billyb (billyb_at_discussions.microsoft.com)
Date: 07/01/04
- Next message: billyb: "Re: Need some advice on ADO .NET"
- Previous message: billyb: "Re: Need some advice on ADO .NET"
- In reply to: William \(Bill\) Vaughn: "Re: Need some advice on ADO .NET"
- Next in thread: William \(Bill\) Vaughn: "Re: Need some advice on ADO .NET"
- Reply: William \(Bill\) Vaughn: "Re: Need some advice on ADO .NET"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 1 Jul 2004 13:11:01 -0700
Hi Bill,
After looking at the TOC of your book, I have two questions:
1) Is the ADO stuff (minus the Dot NET) relevant if I'm exclusively in .NET and am coming from a different background (PowerBuilder)? Just don't want to waste time reading it if it's not.
2) I want to be sure the the topics deal with "real world" examples and situations such as those I describe in my post. (It looks like it, but before I drop some more personal $ I want to be sure.)
Thanks for the helpful post.
Billy
"William (Bill) Vaughn" wrote:
> Yes Billy,
> There are a lot of books out there that don't use best practices. My
> books discuss the problems with these practices and discuss the
> architectural issues you've raised.
> As the other folks have said, ADO.NET (and ADO in general) is an "OSFA"
> interface (one-size-fits-all). It's designed to permit (fairly) low-level
> data access to a variety of backend data access servers and architectures.
> It does not really dictate how your application is designed or approaches
> data access problems. It simply provides the interfaces to the backend. Yes,
> ADO.NET has quite a few classes to support "disconnected" architectures, but
> you can also build connected applications as well. I, for one don't endorse
> "universal" use of the DataReader as some do. I think it's expensive to code
> and debug and if not handled correctly leads to other issues as well. For
> those just starting out in .NET I agree that it's tough to know what's
> "best". The answer is "it depends". As I said, my books talk to these issues
> and are designed especially for those transitioning from ADO classic.
>
> hth
>
> --
> ____________________________________
> William (Bill) Vaughn
> Author, Mentor, Consultant
> Microsoft MVP
> 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.
> __________________________________
>
> "billyb" <billyb@discussions.microsoft.com> wrote in message
> news:9F6C7908-CD64-4A32-A5BE-27D87A29137A@microsoft.com...
> > Just finishing up reading "Pragmatic ADO .NET" from the .NET Developer
> Series. Most of the examples deal with single tables. The ones that don't
> show a very simple relationship like Customer -> Orders.
> >
> > In the examples, the author seems to advocate loading tables into
> DataTables using SELECT * queries, then defining the schemas and
> relationships. My DBA background is cringing at this approach because of
> the full table scans this would needlessly cause.
> >
> > Moreover, I often have relationships that depend on several tables. I
> understand the value of knowing the schema at the ADO .NET level but it
> seems like it comes at a the cost of not allowing the database to do what it
> does best in retrieving only the rows it needs using indexes.
> >
> > Does ADO .NET discourage the use of complex, multi-join queries with
> limiting WHERE conditions or am I grossly misreading things? If I am, can
> someone point me to a good resource that contains real-world examples and
> not just simple, single-table data manipulation?
> >
> > Thanks in advance for any guidance or advice.
> >
> > Billy
> >
>
>
>
- Next message: billyb: "Re: Need some advice on ADO .NET"
- Previous message: billyb: "Re: Need some advice on ADO .NET"
- In reply to: William \(Bill\) Vaughn: "Re: Need some advice on ADO .NET"
- Next in thread: William \(Bill\) Vaughn: "Re: Need some advice on ADO .NET"
- Reply: William \(Bill\) Vaughn: "Re: Need some advice on ADO .NET"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|