Rants Tagged with “ADO.NET”
I've been digging into the latest version of the Entity Framework Beta (and designer CTP) that dropped a few days ago. I've concocted a small example that shows the derivation model in the Entity Framework. Essentially it is a small model that has a Product type and two types that derive from that: ActiveProduct and DiscontinuedProduct:
Figure 1: Simple Model
The new design tools are pretty basic but interesting nonetheless. They seem to be modeled after the LINQ designer (which doesn't make me excited). The designer has a surface to draw types (or they can be created from database metadata) and create relationships between types (as seen in figure 1 above). In addition, there are two information panes: Entity Model Browser and Entity Mapping Details:
Figure 2: The complete Designer Experience (Click image for full size)
The idea of this simple model is to show how you can specify derived types in the designer. The derivation in our case evolves around the Discontinued field in the Products table in the Northwind database. The way that different types are typed in the model is using Conditions. In our case we are typing the database data as a Product if the Discontinued field is NULL (which should never happen really, but the designer doesn't seem to support the notion of an abstract type yet); if the Discontinued field is true (or 1) then its a DiscontinuedProduct type; and if the Discontinued field is false (or 0) then its an ActiveProduct. You can see these mapped in the Entity Mapping Details below:
Figure 3: ActiveProduct Mapping
Figure 4: DiscontinuedProduct Mapping
Once we have the model defined, we can use Object Services to query our data based on type (I could have used LINQ but I think the Entity SQL is clearer in this case):
-- Returns all Products
SELECT VALUE p
FROM NWEntities.Products as p
-- Returns only DiscontinuedProducts
SELECT VALUE p
FROM NWEntities.Products as p
WHERE p IS OF(NWModel.DiscontinuedProduct)
-- Returns only ActiveProducts
SELECT VALUE p
FROM NWEntities.Products as p
WHERE p IS OF(NWModel.ActiveProduct)
Feel free to download the demo (it only works if you have Orcas Beta 2 and the Entity Framework bits installed) and let me know what you think.
The ADO.NET team has been working hard on a new release of the Entity Framework with a boatload of new features (I haven't played with it yet, probalby this weekend). I know they are under some pressure as the June CTP shipped on July 2nd. Check it out if you want to see where they are going.
Caveat, it only works with a June CTP of VS 2008 Expression Web Edition. Not the Orcas Beta 1 or any other edition. I hope they release a VPC soon but I am not holding my breath waiting.
On TheServerSide.NET, my new article introducing the concepts of the Entity Data Model (i.e. Entity Framework, ADO.NET v.Next, etc.). Let me know what you think!
I was reading an article about VB9's XML Literal support and why C# decided not to support it. (Note, I agree with C#'s lack of support for it, but that's not what this post is about). Paul Vick said:
It is extremely risky to tie yourself explicitly to a technology that may or may not be here 15 years from now. Right now, XML is king. But what happens if some other technology comes along and knocks it off its perch? What if things radically shift in some other direction and XML suddenly becomes a side track instead of the main line?
While I agree with this notion, this seems to be the exact reason for *not* including LINQ. Why are they willing to tie the language to a brand-new notion of language integration that might not be here in two years, but they saying they don't want to pollute the language with XML becuase they are not sure it will be here soon?
It seems like they are talking out of both sides of their mouth on this one. If it is important that the language remain clear and simple, why introduce LINQ with the related features (extension methods and variable inference)?
I've gotten the new Visual Studio Orcas March CTP up and running (as the VPC it ships as). I've been playing with the Entity Framework some today and I am pretty impressed so far. Unfortunately the automatic generation of the schema/mapping files still isn't working in this build, but if you write it out by hand it does work. I'll be posting an example soon.
Chris Sells asked me today if there was a re-usable connection string user interface that I knew of. I'd heard that you could use the dialog from Visual Studio, but I had to dig in and remember how. I've put together this quick and dirty example for downloading.
The trick is two fold:
- You need to add Microsoft.Data.ConnectionUI.dll and MicrosoftData.ConnectionUI.Dialog.dll assemblies to your project. (they are found i the VS2005/Common7/IDE directory)
- Next you need to construct the dialog like any other, but first fill it with the standard providers as well as use the static Show method:
DataConnectionDialog dlg = new DataConnectionDialog();
DataSource.AddStandardDataSources(dlg);
if (DataConnectionDialog.Show(dlg) == DialogResult.OK)
{
textBox1.Text = dlg.ConnectionString;
textBox2.Text = dlg.SelectedDataProvider.DisplayName;
}
The sample includes how to find out if the user wants to save the provider and skip that part of the dialog everytime. Let me kow what you think!
After reading this interesting article by Pablo Castro, I have to assume that the real purpose of using Async Execution is for specific use-cases when you need to fire off multiple concurrent queries in service situations (e.g. ASP.NET, Web Services or Windows Services).
There are several interesting observations in this article:
The first one i'd like to point out is in the "Keeping WinForms Applications Responsive" section. He states explicitly that the BackgroundWorker is a better solution than using Async. This means that you should avoid using it in UI-based apps (probably WinForms and WPF).
Another observation is detailed in this quote from the article (emphasis added):
"Note that if you know you'll use a given connection object with synchronous commands only, it's better not to include the async keyword in the connection string, or alternatively include it but set it to false. Execution of synchronous operations on connections that have asynchronous operations enabled will have noticeably increased resource utilization."
This leads me to two conclusions:
- Async connections won't be pooled with non-async (since they have different connection strings).
- You will need to weigh the higher resource utilization against the performance improvement of concurrent query execution to determine whether to use it.
Also, since you can manipulate a resultset from each concurrent query at the same time, it seems that the async keyword also turns on MARS on the connection, but I do not have any evidence of that...just a suspicion.
My advice? Take time and read (carefully) what Pablo Castro has to say in the article and only use the Async functionality when you have a very clear case of concurrent execution in a service environment (ASP.NET, Web Service or Windows Service).
Feedback is encouraged...
The
ADO.NET Team has a blog (in case you aren't already subscribed, do it now). They
blogged today about the performance considerations of accessing Large Objects (LOBs) when using SqlDataReader. Read it now and bookmark it. This is a great
post!
I've blogged before about issues with the SqlDataSource. I've crufted up an example of the problems that can be downloaded here (with usual caveat of changing the connection string in the web.config to point to a DB with the Northwind database).
There are three basic issues:
- The problem is that if a database allows nulls (and a specific row has an NULL) then the automagically created queries in the SqlDataSource will affect zero rows. So data loss can happen without alerting the user.
- The other related issue is that if an Update fires and affects zero rows it is swallowed unless the user handles the DataSource.Selected event.
- Lastly, if your query includes SQL Server Timestamp fields, the SqlDataSource designer doesn't know how to handle it correctly (either by inserting it into the Keys field of the control, or that it isn't a varbinary field).
I want the ASP.NET team to use the SqlCommandBuilder so that we have a common SQL Generationh platform so problems fixed in one place don't re-rear their heads.
In general you can get around these issues by hand-crafting your own SQL (or preferrably using Stored Procs) and handing the Updated and Deleted events in your DataSources. The problem with this is that since SqlDataSources seem to be a good RAD-type tool, then they should work in most databases 'out of the box' and they don't.
Any comments on the code or this issue are certainly welcomed!
In cooperation from Dunn Consulting and Training, we will be offering a new five-day course on Enterprise Data Architecture. The course will teach best practices from the ground up when it comes to implementing data solutions with Microsoft .Net tools and technologies.
We are running a Beta class of this course on September 18th - 22nd for the substantial discount price of $1,750. For complete information see the Dunn Training site:
http://www.dunntraining.com/EnterpriseDataArchitecture.htm
