From DB to DataGrid – So Many Choices!

MiniTutorialLogo

ProjectTuringLogo

 Turing Project Page: [Novice: 6, Advanced: 4]    FAQ    Table of Contents

  What is this and where do I start?

In the previous entry, we created the design for the database. Over the next few postings, we’ll be working with that Data in five distinct ways:

  1. Gather data from the bloggers about themselves, their blog and each entry
  2. Store that data in a database
  3. Extract that data as needed from the database
  4. Transmit the data to a Silverlight application
  5. Display the data in a Silverlight application

Of these five, we’ve made simplifying interim decisions about numbers 1,2 and 5:

Gathering Data

We’ve decided, for now, to gather the data from the bloggers by using a form, though over time we’ll want to migrate to other, better options.

My longer term plan for data entry is to have the blogger “register,” providing us with all the necessary one-time information (e.g., Blog name, URL, etc.) and choose a tag that will indicate that an entry should be in the database. We will then watch the rss feed for that blog, looking for the chosen tag, and we’ll list each tagged entry.

Storing Data

We’ve also decided for now to use SQL Server as our database, though the truth is we can use almost any data store.

Displaying The Data

Finally, we’ve decided to hold off on the Display decisions for now, making do with a very simple data grid  just to check that we’re getting the data we think we’re getting.

Extracting and Transmitting Data – Too Many Choices?

Amadeus

 

Emperor Joseph II: My dear young man, don’t take it too hard.
Your work is ingenious. It’s quality work.
And there are simply too many notes, that’s all.
Just cut a few and it will be perfect.

Mozart: Which few did you have in mind, Majesty?
Amadeus 1984

 

It is possible to complain that Microsoft has provided too many choices for retrieving and transmitting data. Over the past decade we’ve seen RDO, DAO, ADO, COM, DCOM,  ADO.Net, ADO.NET Data Services, Entity Framework, LINQ, ASMX, WCF, RIA Services…

But that would be querulous; after all, each new option (with the possible exception of COM!) has achieved a higher level of abstraction for the programmer; handling more of the plumbing and requiring less repeated, error prone and annoying code in our application.  But yes, it is hard to keep up.

One suggestion that I’ve found helpful,  is to separate the Data Access Layer (DAL), the transport layer and the Business layer, when deciding on which technologies to employ.  That doesn’t necessarily mean three separate sets of classes, but it does mean three distinct concepts. The picture I keep in my head looks (crudely) like this:

WorkFlow

Data Access Layer

For the DAL layer your realistic choices today are

  • ADO.NET
  • Linq to Sql
  • Entity Frameworks

 

ADO.NET Is Not ADO

ADO at one time stood for ActiveX Data Objects, and the original ADOwas the successor to Remote Data Objects (RDO) and Data Access Objects (DAO).  All of this is back in the 20th Century, and is of interest only to those of us who lived through the Dark Ages (the time of COM).

ADO.NET is not named thus because it is the illegitimate child of ADO in any real technical evolutionary sense, but rather to send the message that it is the .NET replacement for ADO; and it has been a hearty replacement indeed.

Impedance Mismatch

When electrical engineers refer to an Impedance Mismatch they mean the need to match up the input impedance of an electrical load to a fixed impedance (most often, the signal they are working with).  This became an irresistible analogy for the problem that object oriented programmers have trying to match up their object model with the relational model most often used in successful databases. (This metaphor has become so entrenched that Wikipedia’s page for Impedance mismatch lists both meanings!)

The key problem, in short, is that relational databases are very (very!) good at storing, updating and retrieving data, but they achieve their terrifying performance at the cost of insisting of thinking about data as consisting of records and fields (rows and columns). 

Entries

 blogs

 Bloggers 

While programmers have had enormous success thinking about objects and their relationships

Objects

In the case shown, the mapping from object to table appears deceptively straight forward, but as your application grows the complexity transcends the fact that properties of an object may not map to a single table: with many applications there simply isn’t an obvious way to build a given object from the provided tables without serious manipulation or compromise.

ADO.NET As A First Layer of Abstraction

ADO.NET was a great first attempt at solving this problem and made life significantly easier. That said, ADO.NET does stay pretty close to the relational model, and the objects in ADO.NET include

  • DataReader
  • DataSet
  • Connection
  • Command
  • DataAdapter
  • DataTable

and so forth.  You certainly can accomplish everything you want; and there may be times you’ll go to ADO.NET specifically because it maps so cleanly to your database, but there are alternatives today that do much of the drudge work of ADO.NET for you. 

In  a future posting, I’ll come back to this exercise and implement it with ADO.NET.

Linq To SQL

LINQ was one of the most significant additions to .NET 3.5. 

Linq to Sql is specifically designed to use LINQ to interact with SQL Server. That is both its power and its Achilles Heel as it is very coupled to the particulars of SQL Server technology.  While Linq To Sql would certainly do the job for us, I’d prefer to use something more flexible, and a bit more decoupled from the database and frankly, something with a bit more object encapsulation

On To Entity Framework

This brings us to Entity Framework; a topic worthy of a full posting, and that will be next in this series on the Advanced track; the Novice track will take a short digression to review Linq, which we’ll be using quite a bit in this project.

Novice Previous:  Data Forms Next: Linq Reviewed
Advanced Previous:  Data Forms Next: LinqToSQL

About Jesse Liberty

Jesse Liberty has three decades of experience writing and delivering software projects and is the author of 2 dozen books and a couple dozen online courses. His latest book, Building APIs with .NET will be released early in 2025. Liberty is a Senior SW Engineer for CNH and he was a Senior Technical Evangelist for Microsoft, a Distinguished Software Engineer for AT&T, a VP for Information Services for Citibank and a Software Architect for PBS. He is a Microsoft MVP.
This entry was posted in z Silverlight Archives and tagged . Bookmark the permalink.