ADO.NET 3.0

Dynamic Data Entities Websites - EntityDataSource and ASP.NET Website Scaffolding - Rapid Application Development ( RAD )

Dave Hayden — Tue, 13 May 2008 10:41:00 GMT

A step-by-step look at the new ASP.NET Dynamic Data Entities Websites Project Template and its use of the new EntityDataSource in Visual Studio 2008 SP1. We''l also re-look at what it takes to wire the ADO.NET Entity Data Model to Dynamic Data and implement Scaffolding. Very cool!

Sarasota .NET Developer Group - Presenting ASP.NET MVC Framework and Data Access Tips and Techniques

Dave Hayden — Mon, 17 Mar 2008 00:47:00 GMT

Sarasota .NET Developer Group - Presenting ASP.NET MVC Framework and Data Access Tips and Techniques

by David Hayden, Florida .NET Developer, Filed: Florida .NET Developer Events

Soon after the Orlando Code Camp, I will be giving 2 presentations to the Sarasota .NET Developer Group at 6:00pm on Thursday, April 10, 2008:

Introduction to the ASP.NET MVC Framework

Create websites using the new ASP.NET MVC Framework from Microsoft. In this presentation we will discuss how the ASP.NET MVC Framework is different from ASP.NET Webforms as well as the strengths and weaknesses of each. We will create routes, views, controllers, and controller factories as well as discuss different ways to communicate between views and controllers. We will also leverage various IoC Tools, like Castle Windsor and Unity, to inject dependencies into controllers as well as use AJAX with the ASP.NET MVC Framework.

Data Access Tips & Techniques

Learn and explore the variety of ways you can access data using ADO.NET, the Data Access Application Block, LINQ To SQL, ADO.NET Entity Framework, ADO.NET Data Services, and the ASP.NET 3.5 Dynamic Data Framework. In this session we will walk-thru and build several examples for each technique as well as discuss tips, strengths, and weaknesses.

I look forward to seeing everyone at the meeting! We will be talking about quite a few technologies...

News Feed: http://www.davidhayden.com/

SQLSaturday - SQL Server Data Access Tips and Techniques with David Hayden - Tampa Florida

Dave Hayden — Sun, 10 Feb 2008 12:07:00 GMT

SQLSaturday - SQL Server Data Access Tips and Techniques with David Hayden - Tampa Florida

by David Hayden, Sarasota Web Developer

I will be presenting at SQLSaturday in Tampa, Florida on Saturday, February 16, 2008.

Here is the abstract:

SQL Server Data Access Tips and Techniques

You have optimized and tuned your SQL Server Database and now you need to access the data from your application. Learn and explore the variety of ways you can access the data using ADO.NET, the Data Access Application Block, LINQ To SQL, ADO.NET Entity Framework, ADO.NET Data Services, and the ASP.NET 3.5 Dynamic Data Framework. In this session we will walk-thru and build several examples for each technique as well as discuss tips, strengths, and weaknesses. Come with your questions and explore the wonderful world of data access to SQL Server!

We only have an hour, so I will be prepared to discuss and demo:

ADO.NET 2.0
Enterprise Library Data Access Application Block
LINQ To SQL
ADO.NET Entity Framework
ADO.NET Data Services
ASP.NET Dynamic Data Websites

This is subject to change, of course, but I thought I would break the presentation into thirds:

20 minutes: ADO.NET and DAAB
20 minutes: LINQ To SQL and ASP.NET Dynamic Data
20 minutes: ADO.NET Entity Framework and ADO.NET Data Services

This isn't a deep technical session. It's goal is to expose you to data access options from Microsoft that exist today and are coming down the pike. I will be happy to answer more technical questions after the presentation.

See you there!

Author: David Hayden, Florida Web Developer

Site: http://www.davidhayden.com/

Creating Data Access Layer Using DbProviderFactories and DbProviderFactory

Dave Hayden — Mon, 08 Oct 2007 18:00:00 GMT

Creating Data Access Layer Using DbProviderFactories and DbProviderFactory

by David Hayden ( Florida .NET Developer ), Filed: ADO.NET 2.0

I know I have mentioned DbProviderFactories and DbProviderFactory in ADO.NET 2.0 before, but they were new to some developers this weekend so I thought I would reiterate their use in a database agnostic data access layer in your winform and ASP.NET Web Applications.

If you look at the connection string in your App.Config or Web.Config:

<add
    name="ConnectionString"
    connectionString="server=.;Initial Catalog=Northwind;..."
    providerName="System.Data.SqlClient"
/>

you will notice the providerName Property, which represents the unique name for the .NET Framework data provider used to connect to an underlying data source.

In this case we are connecting to SQL Server, but we don't really need to know that. We can use that providerName to create various connection, command, and other database classes without knowing what type of database we are connecting to by using the DbProviderFactories and DbProviderFactory Classes.

First, let's get the actual connectionString and providerName that make up the database we are connecting to using System.Configuration.ConfigurationManager:

string connectionString =
    ConfigurationManager.ConnectionStrings
    ["ConnectionString"].ConnectionString;
    
string providerName = 
    ConfigurationManager.ConnectionStrings
    ["ConnectionString"].ProviderName;

Once we have the providerName, we can create a DbProviderFactory class for the database using the DbProviderFactories Class:

DbProviderFactory provider =
    DbProviderFactories.GetFactory(providerName);

The DbProviderFactory Class exposes several methods that allow us to create classes to access the database:

CreateConnection()
CreateCommand()
CreateParameter()
CreateDataReader()
CreateDataAdapter()

Again, keep in mind that it does not matter what database we are using at this point - could be SQL Server, Oracle, Microsoft Access, DB2, Firebird, etc. Pick your poison.

Assuming the database supports stored procedures, we can call a stored procedure in a database agnostic way as follows:

using (DbConnection cn = provider.CreateConnection())
{
    cn.ConnectionString = connectionString
    
    using (DbCommand command = cn.CreateCommand())
    {
        command.CommandText = "GetAllCustomers";
        command.CommandType = CommandType.StoredProcedure;

        cn.Open();
        
        using (DbDataReader dr = command.ExecuteReader())
        {
            // Do Something...
        }
    }
}

This is an awesome way to target multiple database with your application.

Don't forget you can do some really cool stored procedure parameter discovery as well:

SqlCommandBuilder.DeriveParameters - Get Parameter Information for a Stored Procedure - ADO.NET Tutorials

All good O/R Mappers and Code Generators for the Data Access Layer handle all of this data access layer database agnostic code for you, but it is still good to know what is happening behind the scenes.

Hope this helps!

Similar ADO.NET Tutorials

by David Hayden ( Florida .NET Developer ), Filed: ADO.NET 2.0

LINQ to SQL Performance and Prepared Statements

Dave Hayden — Fri, 06 Jul 2007 00:33:00 GMT

LINQ to SQL Performance and Prepared Statements

by David Hayden ( Microsoft MVP C# ), Filed: LINQ to SQL

Rico Mariani has an interesting series of posts on LINQ to SQL Performance with Part 4 giving some numbers on the performance of LINQ to SQL compared to raw ADO.NET ( DataReader ).

I don't know if you can read a lot into those numbers other than 1) there has been a lot of improvement in LINQ to SQL performance and 2) there are some ways to improve LINQ to SQL performance- like using compiled queries when running the same query many times.

What got me thinking in the post was not the performance numbers, but this simple statement:

“However I didn't go to the trouble of creating prepared statements for update and insert cases, DLinq gives you this automatically.”

Interesting statement that suggests calling SqlCommand.Prepare() is a lot of effort. Huh? Makes me now wonder two things:

What his insert and update commands look like using straight ADO.NET?
What the performance numbers would look like if he did use prepared statements?

I am under the impression that SQL Server 2005 is pretty smart about handling and caching execution paths, etc. so the use of prepared statements is not as dramatically beneficial as it may be in earlier versions of SQL Server. However, this is something I would have loved to see Rico test just to see if there was a difference.

I now feel those “DLINQ is Faster” observations for update, compiled update, and insert are less interesting since I don't have the prepared statement tests. Is use of prepared statements why LINQ to SQL is faster in those scenarios? Seems incomplete...

Source: David Hayden ( Microsoft MVP C# )

Filed: LINQ to SQL

ADO.NET Entity Framework - When To Use It vs. Linq to SQL

Dave Hayden — Sun, 29 Apr 2007 23:30:00 GMT

ADO.NET Entity Framework - When To Use It

by David Hayden ( Florida ASP.NET C# SQL Server Developer )

I mentioned earlier that the ADO.NET Entity Framework was Cut From .NET 3.5 and Visual Studio Orcas and we will have to wait until the first half of 2008 to see a release. In the meantime there is Linq to SQL which I have played with quite a bit and enjoy for O/R Mapping. I showed a trivial example of it not too long ago:

Linq to SQL Example Tutorial - Visual Studio ORCAS March 2007 CTP - ASP.NET

Right after the announcement that the ADO.NET Entity Framework was cut from .NET 3.5, the data access team at Microsoft came out with their strategy for data access that is worth reading here.

I really liked the part that discusses when to use the ADO.NET Entity Framework which I cut and pasted below. Most of it is about the ability to define Client Views on existing database schemas so that you can work with the data logically in the client application as opposed to being limited by the database schema. This is a great feature and one I was really looking forward to.

Anyway, here is when to use the ADO Entity Framework according to Microsoft:

“If you are writing an application that requires any of the following features, you should use the ADO.NET Entity Framework:

The ability to define more flexible mapping to existing relational schema, for example:

Mapping a single class to multiple tables
Mapping to different types of inheritance
Directly Modeling Many to Many relationships
Mapping to an arbitrary query against the store

The ability to query relational stores other than the Microsoft SQL Server family of products.
The ability to share a model across Replication, Reporting Services, BI, Integration Services, etc.
A full textual query language
The ability to query a conceptual model without materializing results as objects”

In the post mentioned above, Linq to SQL is portrayed as more of a rapid development approach for simple projects where the database schema is the domain model and you are using SQL Server. Fair enough. I need that, too :)

Source: David Hayden ( Florida ASP.NET C# SQL Server Developer )

ADO.NET Entity Framework Cut From .NET 3.5 and Visual Studio Orcas

Dave Hayden — Sun, 29 Apr 2007 10:31:00 GMT

ADO.NET Entity Framework Cut From .NET 3.5 and Visual Studio Orcas

by David Hayden ( Sarasota Web Design )

The recent announcement about the ADO.NET Entity Framework being cut from .NET 3.5 and Visual Studio Orcas and instead being shipped during the first half of 2008 has me bewildered this morning. Frans speculates on the decision. I am just disappointed with Microsoft's abililty to deliver solutions as promised, on-time, and with timely maintenance releases and service packs.

News Feed: David Hayden ( Sarasota Web Design )

ADO.NET vNext Entity Data Model Designer Prototype CTP

Dave Hayden — Thu, 28 Sep 2006 10:26:00 GMT

Interesting download of what may be coming in the future with respect to ADO.NET -

“The “ADO.NET vNext Entity Data Model Designer Prototype CTP” enables developers to design their data access stack using a designer in Visual Studio.

This is an unsupported tool that showcases upcoming ideas for ADO.NET vNext tooling and Visual Studio integration. It also illustrates how ADO.NET vNext developers might use Visual Studio to design their data access layer

The designer in this CTP has limited functionality and only lets you design the “Conceptual” layer. There is no support for visually editing mappings (MSL file) or storage (SSDL file) in the designer.”

Download it here.

Entity Data Model Related Posts

Author: David Hayden ( Sarasota Web Design )

Filed: ADO.NET Entity Data Model

ADO.NET vNext will not be included in .NET 3.0 - ADO.NET Entity Framework

Dave Hayden — Tue, 05 Sep 2006 12:18:00 GMT

Pablo Castro, ADO.NET Technical Lead at Microsoft, just dealt the development community a huge blow by mentioning in the MSDN Forums that ADO.NET vNext will not be included in .NET 3.0.

"ADO.NET vNext will not be included in .NET 3.0. (that's why we're just calling it "vNext" for now)." - Pablo Castro

Microsoft is being really slow to deliver o/r mapping technology. We could have used the ADO.NET Entity Framework years ago when they were talking about ObjectSpaces.

I think this goes hand in hand with Microsoft always wanting to deliver new versions of software that completely change development. I would rather they deliver smaller, usable solutions incrementally that provide a migration path to future solutions.

Source: David Hayden ( Sarasota Web Development )

Filed: ADO.NET vNext

The Database Model is the Domain Model - Applying Domain-Driven Design and Patterns - O/R Mappers

Dave Hayden — Thu, 24 Aug 2006 16:06:00 GMT

Frans Bouma has posted an essay entitled The Database Model is the Domain Model on his blog. I haven't read it completely, but it looks to be similar to what Frans had written in Appendix A, entitled Other Domain Model Styles, in Jimmy Nilsson's book Applying Domain-Driven Designs and Patterns. You can read my review here:

Applying Domain-Driven Design and Patterns by Jimmy Nilsson - Examples in C# and .NET

As you can tell by the title, The Database Model is the Domain Model, Frans is suggesting that the domain model and the database model in your applications are the same. This is certainly the approach he uses in his O/R Mapper, LLBLGen Pro, where entities and their relationships are based on the database model.

In more cases than not, I find this to be true and desirable for a few reasons:

It is really easy to go back and forth between the domain model and the database model, because the entities and relationships are identical.
The queries and code responsible for object relational mapping is straight forward and easy to understand.
Domain-model concepts like ActiveRecord and Data Access Objects play well in this model and are very easy to understand and maintain.
Code generation and RAD tools can be applied in most cases with great efficiency.

When your domain model starts to move away from your database model you start to reduce the benefits above. This isn't to say that doing so is a bad thing as in theory object-oriented programming and the database have different goals. With a database you try to normalize data, and with OOP you try to normalize behavior.

The nice thing about ADO.NET vNext, is that the ADO.NET Entity Framework has the concept of the Entity Data Model, which can vary from the Database Model and allow you to break away from the database model when necessary. I still like to keep the models as close as possible because I believe it makes the applications easier to maintain and understand, but it doesn't always work out so cut-and-dry.

Source: David Hayden ( ASP.NET Web Developer )

Filed: ADO.NET vNEXT, O/R Mapping, Code Generation