The team has been hard at work, as always, to bring some really neat new features to Telerik OpenAccess ORM for Q2 2011.  You can check out the release notes to see the full list of new features, but make sure to sign up for the release webinar to see all these new features in action!  For now, we will take a quick look at a few features available in the new bits.

Profiler and Tuning Advisor

One of the most anticipated features in the Q2 2011 release is the OpenAccess Profiler. In Q1 2011 we introduced a new Metrics API, and the profiler uses this API to monitor everything OpenAccess is doing under the covers. The profiler can show date from live applications, or review data saved from previous profiling sessions. The profiler aims to make it easier than ever for developers using OpenAccess to see the SQL generated for different LINQ queries, and highlight potential problem areas.



OpenAccess captures a large number of events, and metrics, during a profiling session.  To make it easier to work with all of this data, the profiler provides developers many different filtering capabilities.  As the filters are applied, the grids below are updated to show only the data matching the criteria.  This makes filters a really handy tool when trying to hone in on a specific issue.



The profiler allows developers to see the SQL OpenAccess generates, and quickly jump to the LINQ statement or API event that triggered the SQL.



When looking at the SQL, LINQ, or API events, developers are also presented with a full stack trace making it very easy to discover the call site.



In addition to these features, the new OpenAccess profiler provides analysis and warnings about potential issues.  The analysis system provides alerts for situations like n+1, and long running queries, and goes a step further by suggesting ways to resolve the issues.   



Low Level API

Another great feature available in the Q2 2011 release is the new fast low level API. Developers familiar with ADO.Net will find the new API very similar. In the this initial version our main focus was on providing a better story for really complex setups that require native SQL execution, materialization of objects that are not entities, traversal of multiple resultsets and better stored procedure handling. In addition, the new API still works with all of the RDBMS OpenAccess supports

This new API can map stored procedure, and direct SQL, results to persistent types, or it can do direct projection to non-persistent types.  Obviously when projecting to a non-persistent type,  change tracking capabilities are lost, but in many read-only cases this is perfectly acceptable, and may even be preferred! So lets take a look at some code samples :)

For the first example I will show how to execute the “Employee Sales By Country” stored procedure in the Northwind database, and return the results as a collection of non-persistent types. The first thing we need is a class with the columns we want to return (mismatched/missing names are simply ignored). 

public class EmployeeSalesByCountry
 public string Country { get; set; }
 public string LastName { get; set; }
 public string FirstName { get; set; }
 public DateTime ShippedDate { get; set; }
 public int OrderId { get; set; }
 public decimal SaleAmount { get; set; }

Next we create a method that creates a few parameters, and calls the stored procedure using the new ExecuteQuery<> command available from the OpenAccess context.

public IEnumerable<EmployeeSalesByCountry> GetEmployeeSalesByCountry(DateTime start, DateTime end)
   OAParameter startDateParam = new OAParameter();
   startDateParam.ParameterName = "@Beginning_Date";
   startDateParam.Value = start;
   OAParameter endDateParam = new OAParameter();
   endDateParam.ParameterName = "@Ending_Date";
   endDateParam.Value = end;
 //context is an OpenAccess Context
 return context.ExecuteQuery<EmployeeSalesByCountry>("Employee Sales by Country", System.Data.CommandType.StoredProcedure, startDateParam, endDateParam);

That is all we need to do! No need to set up any mapping code because OpenAccess will figure it out for us. :)

You might notice a new OpenAccess construct, OAParameter used in this example.  A standard DbParameter could be used instead, however using the OAParameter ensures that the generated SQL makes sense to the underlying RDBMS.  We also provide OAReader, OACommand, and more for the same reason.  You can actually use the standard ADO.Net objects, and let OpenAccess handle the nasty mapping for you using the new Translate<> command:

string connectionString = ConfigurationManager.ConnectionStrings["NorthwindConnection"].ConnectionString;
using (SqlConnection connection = new SqlConnection(connectionString))
 using (SqlCommand command = connection.CreateCommand())
       command.CommandText = "Select * From Products";
 using (SqlDataReader reader = command.ExecuteReader())
 //Here we tell the OpenAccess context to handle mapping the data reader to a list of ProductProjections
           IEnumerable<ProductProjection> products = context.Translate<ProductProjection>(reader);          


That’s it for now, I will leave the rest of the updates for the webinar; so make sure to sign up for it.  :)

Download Q2 2011 today and start taking advantage of all these great new features!


Happy Coding!


Comments are disabled in preview mode.