From DB to DataGrid – So Many Choices!
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:
- Gather data from the bloggers about themselves, their blog and each entry
- Store that data in a database
- Extract that data as needed from the database
- Transmit the data to a Silverlight application
- 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?
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:
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).
While programmers have had enormous success thinking about objects and their relationships
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.