Tuesday, October 26, 2010

Using OpenAccess in LINQPad

Have you ever wanted to have a simple "scratchpad" for testing LINQ queries with OpenAccess ORM? LINQ is a great querying language, but sometimes it can be difficult to figure-out exactly how to craft those complex LINQ queries.  And while it's possible to go the route of "make a change, build, and see what happens," it's a huge waste of time.

Enter LINQPad, a simple tool that is perfect for quickly testing queries with OpenAccess ORM. LINQPad, for the uninitiated, is really a great scratchpad for testing any .NET code, but it's particularly useful for quickly testing LINQ queries (especially with the "pro" IntelliSense enabled).

Earlier this year, Steve Scott (aka Sitefinity Steve) posted some quick instructions for using OpenAccess with LINQPad, which was a very useful, simplified follow-up to an OpenAccess Team blog post from last year. OpenAccess has a change slightly since both of these posts were created, so here are quick updated instructions for querying OpenAccess with LINQPad.

The first step after launching LINQPad is configuring Assembly References and Namespaces. To do this, press F4 and add the following:

  • Under "Additional References":
    • Telerik.OpenAccess.dll
    • Telerik.OpenAccess.35.Extensions.dll*
    • <Your OpenAccess Enhanced DLLs>
  • Under "Additional Namespaces":
    • Telerik.OpenAccess
    • <Your Assembly Namespaces>

If you're using the new RLINQ OpenAccess DataContext, you should reference Telerik.OpenAccess.40.Extensions.dll instead of the "35" version. The "35" version is appropriate for assemblies using IObjectScope (pre-RLINQ). Your config should look something like this:


Now that LINQPad is configured, you can start querying! Only two steps are required:

1. Change the LINQPad editor Language to C# (or VB) Statement(s)

2. Write your query code, including scope initializer and LINQPad "dump":


Result? You can now start testing away with your LINQ queries and view the results in the LINQPad Results viewer. Clearly, if you're using RLINQ, you can skip the "GetNewObjectScope" and proceed directly to querying the DataContext. The connection string will default to what's stored in your DLL's App.Config. Finally, you're not limited to direct LINQ query testing. If you have repositories in your DAL, you can also test your data access using your repositories in LINQPad, too.

Since this approach to using OpenAccess in LINQPad does not implement the LINQPad provider model, the SQL dump is not available. LINQPad's provider model provides a simple way to expose the SQL dump for OpenAccess, but only for the newer RLINQ contexts. If there is interest, I will work on providing a simple OpenAccess driver for LINQPad that supports RLINQ to unlock the remaining features, like the schema explorer and SQL dump window.

Great ORMs require trust, and there is no easier way to build that trust with your ORM than to have a quick way to test and verify your queries. With a few simple steps, LINQPad and OpenAccess ORM can give you that simple tool and speed-up your data access productivity!