Using the ADO.NET Entity Framework

The ADO.NET Entity Framework is an object-relational mapping (ORM) framework for the .NET Framework. Developers can use it to create data access applications by programming against a conceptual application model instead of programming directly against a relational storage schema. This model allows developers to decrease the amount of code that must be written and maintained in data-centric applications.

This section describes data provider features that relate to the ADO.NET Entity Framework as follows:

• Migrating a Project from Another Data Source
• Using Stored Procedures with the ADO.NET Entity Framework

Migrating a Project from Another Data Source

Some developers start their ADO.NET Entity Framework projects with Microsoft SQL Server, and then migrate the projects to an enterprise-wide data source such as DB2, Sybase, or Oracle. While this practice might seem to be convenient, the migration cost can be expensive.

Data sources such as Microsoft SQL Server include boolean types, and porting applications to a data source that does not support boolean types could incur an unacceptable overhead. For example, meticulous and error-prone editing of Entity Framework mapping files could be required.

Refer to "Mapping Data Types" for your Entity Framework data provider for more information.

Using Stored Procedures with the ADO.NET Entity Framework

The DataDirect Connect for ADO.NET Entity Framework data providers support multiple result sets and return codes from stored procedures when parameters are bound as return codes. The stored procedures must take an argument list.

Refer to the DataDirect Connect Series for ADO.NET Reference for more information about using stored procedures.

Using Named Parameters

Using named parameters in stored procedures lets you bind parameters by name. This means that you do not have to enter the parameters in order.

Using Pseudo Stored Procedures

The Connection object includes properties and methods that provide reauthentication and enhanced statistics functionality. The methods and properties are standard in the ADO.NET data provider, but are not available at the ADO.NET Entity Framework layer. Instead, you expose the same functionality through "pseudo" stored procedures.

This approach uses the Entity Data Model (EDM) to achieve results that correspond to the ADO.NET results. This in effect provides entities and functions backed by pseudo stored procedures.

The following table lists the mapping of the Connection properties to the corresponding pseudo stored procedure.

Mapping to Pseudo Stored Procedure

1 DB2 and Oracle Entity Framework data providers only.

You can create a function mapping in the entity model to invoke the pseudo-stored procedure. Alternatively, applications can use the ObjectContext to create a stored procedure command as shown in the following C# code fragment:

using (MyContext context = new MyContext())
{
   EntityConnection entityConnection = (EntityConnection)context.Connection;
   // The EntityConnection exposes the underlying store connection
   DbConnection storeConnection = entityConnection.StoreConnection;
   DbCommand command = storeConnection.CreateCommand();
   command.CommandText = "DDTek_Connection_EnableStatistics";
   command.CommandType = CommandType.StoredProcedure;
   command.Parameters.Add(new OracleParameter("cid", 1));
}
 
bool openingConnection = command.Connection.State == ConnectionState.Closed;
if (openingConnection) { command.Connection.Open(); }
int result;
try
{
   result = command.ExecuteNonQuery();
}
finally
{
   if (openingConnection && command.Connection.State == ConnectionState.Open)
   {
      command.Connection.Close();
   }
}

Using Overloaded Stored Procedures

Using stored procedures with the ADO.NET Entity Framework requires mapping functions. Calling these stored procedures is complex and requires some coding.

If you have multiple overloaded stored procedures, the Entity Framework data provider appends an identifier to each stored procedure name so you can distinguish between them in the SSDL. The data provider removes the appended identifier before calling the stored procedure for your application.