Why not ORM: OpenAccess Watcher, Part 3

In part 1 of this ongoing series, we dispelled ORM myths, shaking the errant assumptions that many developers still hold about ORM. In part 2, we took a deeper look at why and how you can learn to trust the SQL an ORM produces. In part 3, we'll examine a simple tool I've crafted to help with that SQL visualization when using Telerik's OpenAccess ORM.

WHAT DOES THE TOOL DO?

The goal for this tool is simple: make it simple to visualize and summarize in real-time the SQL output from any OpenAccess-powered application. My self-imposed requirements were simple, too:

• The tool must add value above and beyond what OpenAccess' built-in logging provides
• The tool must be easy to setup with any application (win or web)
• At most, 1 assembly reference, 1 line of "initialization" code
• The tool must work with "new" (Visual Designer) and "classic" (IObjectScope) OpenAccess

THE RESULT: OPENACESS WATCHER

The tool, which I've dubbed OpenAccess Watcher, is composed of two parts:

1. The Watcher- This is a simple WinForms application built with the Telerik RadControls for WinForms and the SharpDevelop TextEditor (for syntax highlighting) that "listens" for messages from OpenAccess applications.
2. The Sender- This is a custom OpenAccess TraceListener that builds on the built-in OpenAccess logging to format and send messages in real-time to The Watcher, which in turn handles the visualization. There is also some advanced use of JustMock's CodeWeaver, but more on that in a moment.

The key thing to understand is that (for the most part) this tool is working with the same data you might find in the OpenAccess logs. It's value is in the summary stats it provides, the easier data navigation and visualization, and the "real-time" nature of the log output.

USING OPENACCESS WATCHER

Sticking to my requirements, OpenAccess Watcher requires minimal setup. To use it in an OpenAccess-powered app, you must simply:

1. Add a reference to the assembly that contains "The Sender" (OpenAccessWatcher.Listeners.dll)
2. Initialize the custom TraceListener during your application startup
• For Web, this means 1 line of code in Application_Start in Global.asax
• For Win, this means 1 line of code in your Program's Main method

That's it! Two steps. Now all you need to do is open "The Watcher" and start your application. If everything is working, you'll start seeing OpenAccess generated SQL show-up in The Watcher. (A complete "Getting Started" readme is available with the code.)

UNDERSTANDING THE LOG DATA

Since this tool does depend heavily on the OpenAccess log data, it's important to understand what's available. First, what's available is directly connected to the level of logging you've configured. The three common modes are:

• Normal - This is good for capturing the basic SQL statements, but omits most of the log data that can be used to interpret other behaviors (like row count).
• Verbose - This is good for capturing most SQL behavior, including connections, but it can significantly slow the execution of some applications.
• All - This gives you maximum logging data and enables you to measure things like total rows returned and total data readers opened. Unfortunately, this can really slow down bigger apps.

My suggestion: Start with verbose. If that makes your app unbearably slow, try using normal. If your app runs tolerably with verbose and you want to try to get event more data, then give all a try.

It should also go without saying, these are not settings for production or for measuring application speed. These are settings specifically designed for visualizing SQL behavior during development, with the goal being to use the info for tuning ORM performance configuration.

EXAMPLE APP

To test OpenAccess Watcher, I've got a simple WinForms application with a RadGrid that loads data using the OpenAccessDataSource. When I open the page with this grid, I see the following in Watcher:

There are three primary areas of information:

1. SQL Activity Log (A) - This is a raw log of the SQL queries generated by OpenAccess (pulled from the OpenAccess logs). This data is displayed in a RadGrid for WinForms, so you have the complete ability to sort, filter, and group this data.
2. SQL Visualizer (B) - Using the open source ShareDevelop TextBox, this area better visualizes the selected SQL statement so that you can easily review the SQL with syntax highlighting.
3. Statistics Summary (C) - This area displays the values from various logging counters that summarize OpenAccess database activity. The version of OpenAccess you're using and your logging settings will impact that values that are available here.

While I'll save a full discussion of how to work with this data for Part 4, it's worth noting now that there is not a one-to-one relationship between SQL queries and database connections. OpenAccess typically prepares and executes multiple queries in batch, so don't freak out if you see larger numbers of queries.

ADVANCED LOGGING: CODE INJECTION

As I alluded to above, I am making use of Telerik's very cool CodeWeaver library, available with JustMock, to do IL injection with OpenAccess assemblies. This allows the custom TraceListener to go beyond tracking OpenAccess log data and inject code in to key OpenAccess methods that is used for gathering statistics.

Newer versions of OpenAccess (Q3 2010+) have convenient IntelliTrace and CommandWrapper classes through which all OpenAccess connections and transactions pass, so by injecting some counters in these methods I am able to report on connections and transactions even when logging is tuned-down or disabled.

For older versions OpenAccess, I am not able to do counters as easily, but there is still some injection in to the very low-level Transaction and Connection runtime implementations to help gather as many stats as possible for the visualizer.

In all cases, the code injection tooling will only work when the JustMock profiler is enabled. When not available, you'll get fewer stats.

IT WORKS ON MY MACHINE DISCLAIMER

This is an experimental project. It is not guaranteed to work with your setup. If it doesn't, I'm sorry. Send me feedback and I'll see what I can do to make it cover more scenarios. Known caveats with this preview:

• I'm primarily focusing on SQL Server scenarios today. It should work for other OpenAccess providers, but I haven't tested that yet.
• I've only tested this with .NET 4.0 projects. I'm not sure what will happen if you try to use the custom TraceListener with older .NET versions.
• Your application probably needs to be running in full trust to support the reflection and code injection tooling that's going on.
• The UI of the WinForms app can "hang" when huge volumes of logging data are being collected. Just wait a few seconds and it should become more responsive.

THE BITS

Disclaimer out of the way, here are the bits. Enjoy and share your feedback.

In Part 4, I'll show you how you can use The Watcher to start learning and optimizing the SQL generated by OpenAccess. Since OpenAccess has powerful configuration and optimization options, it's surprisingly easy (compared to other ORMs) to tweak once you have a clear understanding of what's happening.

Why not ORM: Trusting SQL, Part 2

In part 1, we examined and busted 5 common ORM myths. Actually, we busted 4.5. We agreed that one myth, that you can't trust the SQL an ORM produces, is plausible. Let's bust that myth, at least bust it for OpenAccess ORM, today.

IN TOOLS I TRUST

One of the biggest barriers to adopting any time saving development tool is trust. You have to trust that the work the tool is doing to save you time is of equal or better quality than the same work you would otherwise do by hand. A development tool is in many ways like a co-worker or contractor. You have to get to know the results they produce before you can stop worrying about including their output in your project.

This is true for refactoring tools (like JustCode), UI components (like the RadControls), and especially true for data tools like OpenAccess ORM.

But how do you go about "trusting" a tool like OpenAccess ORM? Transparency.

OPEN THE BLACK BOX

With ORMs, many fears root in the perceived "black box" nature of what's happening under the covers. Many developers are familiar with hand crafting EACH-and-EVERY-sql-statement, and it can be unsettling to let some ORM robot start automagically creating your SQL based on abstracted LINQ. What if the SQL is inefficient? What if way too much SQL is being generated? What if the ORM "select *" my database?!

The result of this fear is often cut-and-run. Dump (or don't start using) the ORM and stick with time-wasting, but 100% transparent hand coding.

What developers need is an easy way to open the ORM black box and see what's really happening. Cut-out the "what ifs," and replace them with "when I do X, the ORM will do Y."

WHAT *IS* REALLY HAPPENING?

While ORMs like OpenAccess are unbelievably sophisticated, giving you the power to map database objects to code and even update schemas from code-based models, at the very root of the implementation is code you know. Standard (best practice) .NET for moving data between various databases. In the case of SQL Server, you'll find ADO.NET and SqlCommands, Transactions, and Connections.

The important thing to know is that this "standard" code is built by super-smart developers that are 100% focused on best practice data programming. Think about that. When you use a well built ORM, it's like adding a .NET data programming expert to your team, freeing you to really focus and be an expert on other layers of your app.

Then there's the SQL. And here it's worth noting, not all ORMs are created equal. The way an ORM converts LINQ or OQL or whatever in to SQL, and the ability on top of that to optimize the SQL through configuration, is often what makes one ORM better than another. With a quality ORM, though, you get SQL generated by programmers that are again 100% focused on SQL programming.

Now, much like you must "speak Google" to get the search results you expect, you usually need to learn how to "speak ORM" to get the SQL output you expect. That means you need to form an understanding of how the abstracted data languages (usually LINQ) produce SQL so you know when extra optimization configurations are needed. Do that, and there is no reason the SQL created by an ORM will be any different than the SQL you would create by hand (it may even be better!).

A good ORM is more than a tool. It's a .NET data programming and SQL expert. But how do you prove that to yourself? And how do you learn to speak ORM?

THE ORM LOOKING GLASS

You should never blindly trust any tool. Just as I'd expect you to inspect the HTML produced by the Telerik Extensions for ASP.NET MVC, I'd expect you to inspect the SQL produced by OpenAccess. Doing so not only helps you learn when and how to optimize ORM programming, but it helps you build the trust in your essential data tool.

Fortunately, OpenAccess provides a couple ways to open the "black box" out of the box:

1. Logging
   If you've never used OpenAccess logging, you may be amazed at what can be easily logged with the simple change to a couple of config settings. All SQL statements, parameter values, database connections, and even returned rows can be captured by OpenAccess logging for your thorough review. Logs can be output to the console, a text file, or even directly to a in-memory StringWriter, and volume of data that is captured depends on your logging level. More on that in the next post.
2. IntelliTrace
   For added runtime debugging transparency, OpenAccess (as of Q3 2010) provides deep insight with integrated IntelliTrace support in Visual Studio 2010. As you step and debug your app, IntelliTrace can reveal the SQL OpenAccess is producing and executing.

Both of these approaches are useful, but they do require you to manually "parse" the logs or trace stacks to understand what's happening when your program runs. Is there an easier way to see the bigger picture?

WATCHING OPENACCESS

Taking advantage of the OpenAccess logging output via a custom TraceListener (along with a few other tricks for newer versions of OpenAccess), I've created a simple tool designed to help you better visualize what OpenAccess is doing when your application runs.

The advantages of this tool:

• Easier to visualize, syntax-highlighted SQL
• Convenient log sorting, filtering, and grouping (provided by RadGridView)
• Summary values for key behaviors (total connections, total queries, total transactions, etc.)
• Real-time visualization of OpenAccess output

In part 3, I'll provide a more complete overview of this new tool and provide a basic working version that you can try with your own OpenAccess-powered applications. The main idea behind this tool: make it dead simple to open the OpenAccess black box and visualize the "real" SQL.

Whether you use built-in logging output or a visualization tool like this, take the time to get to know your ORM. If you can build a trust with a powerful ORM, like OpenAccess, you'll leave hand-coding data access in the past where it belongs and never look back.

Can you trust the SQL produced by an ORM? Definitely! You just need to take a look. It's not in a book…it's in a log file.

Why not ORM: 5 ORM myths dispelled, Part 1

Let's start with a DISCLAIMER: If you are already an active user of any ORM, this specific post is not for you. I'll talk to you later. For everyone else, let's continue.

In my role as a technical evangelist, I get the chance to travel the globe and talk to developer audiences on a regular basis. To keep a clear picture of how developers are working, I often informally poll audiences and try to listen for trends in development behavior. One trend that continues to stand out is how many developers still do all data access by hand!

What do I mean "by hand?" I mean manually creating and destroying ADO.NET objects (like SqlConnection and SqlCommand) to move data between apps and data stores. (This includes developers that use tools to simply auto-generate "by hand" code- that's just saving keystrokes.)

Does that describe you? Hopefully it does to a certain degree (otherwise you've overlooked and/or disregarded the DISCLAIMER). You need to stop. You need to reevaluate how and why you're building applications.

DON'T DEVELOP LIKE IT'S 1999

I'm going to talk primarily to web developers, A) because it's what I know best, and B) because I know many readers of this blog are just that. Think back to web development circa 1999 and good 'ol "classic" ASP. We've moved well beyond the days of those spaghetti code script pages, but let's illustrate how data access was commonly done:

Dim Conn
Dim SQLTemp

Set Conn = Server.CreateObject("ADODB.Connection")
Conn.connectionstring =
 "Provider=Microsoft.Jet.OLEDB.4.0;Data
 Source=" & Server.MapPath("\database_name.mdb")& ";"
Conn.Open

SQLTemp = "SELECT * FROM table_name"
set rstemp=Conn.execute(SQLTemp)

Do While Not rstemp.EOF

rstemp.Fields("field_name").Value

rstemp.MoveNext
Loop

Conn.Close
Set Conn = Nothing

You created a connection object. You created a command. You executed it and looped through the results. And in an application working with lots of data, you did this over, and over, and over…

Fast forward to the modern .NET era. If you're still doing data access "by hand" (or having a tool generate code for you), you are probably doing some variant of this:

SqlConnection conn = new SqlConnection("connection string...");

SqlDataReader rdr = null;

try
{
   conn.Open();
   SqlCommand cmd = new SqlCommand("select * from Customers", conn);

   rdr = cmd.ExecuteReader();

   while (rdr.Read())
   {
       Console.WriteLine(rdr[0]);
   }
}
finally
{
   //Clean-up...
}

An improvement syntactically over VBScript, yes, but in concept it's the same old "naive" model for working with data: create connection, create command, execute and process results. Sure, you can wrap this in a pretty "framework"- you pass-in SQL, you get back a DataSet- but you're still doing pretty "raw" data access. There is no "software intelligence" helping you look for opportunities to lazy load data, optimize SQL, or cache data efficiently. That's all on you! There must be a better way.

 

THE MIGHTY ORM

 

Ah, ORM- that's Object Relational Mapper, for the uninitiated. Tomes have been written about ORM over the years, its benefits, its problems, its limits. Boil it all away and a good ORM (generally speaking) has a simple goal: make it easier to for developers to work with data. Data access is not rocket science. Information sitting in structured tables on disk needs to be retrieved and loaded in to memory for an application to do additional processing. Things get a bit harder when you introduce the real world complexities of a reliable, performant system. Data access needs to be fast, it needs to ensure data integrity, and it needs to be efficient so it doesn't "hog" server resources.

 

Still, these are well defined problem areas that don't change from application to application. These are the kinds of narrow, well-defined problems robots (i.e. software) are really good at solving. So that ultimately begs the question…

 

WHY DON'T YOU USE ORM

 

If there are tools, like ORMs, that make data access easier without compromises, then why would anyone (you!) continue to do data access by hand? I have some theories. I think there are some powerful myths surrounding ORMs that prevent hard working developers from realizing ORM benefits:

1. MYTH #1: ORMs are difficult to configure, Learning curves are too steep
   A common myth surrounding ORM is that in the time it would take to configure and learn the ORM system, you can finish creating the data access you need by hand with time to spare. This myth earns its reputation honestly. In the early days of ORM, there were few options for .NET, and those that did exist, like NHibernate, did require some pretty gnarly XML configurating. But that was then.
   
   Today, .NET developers have a host of ORM options, some of which can have you up and running in minutes. Take LinqToSql or OpenAccess ORM. Both provide simple visual designers that let you easily configure an ORM data context in seconds. OpenAccess even provides wizards on top of the designer to further streamline the setup process. Entity Framework, while more complex, also offers a rich visual designer.
   
   CONCLUSION: Myth busted. The ORMs of today are easy to configure. If you're avoiding ORM because you remember the XML config days, it's time to look again.
   
   
2. MYTH #2: I can't give-up Stored Procedures, and ORMs don't use Stored Procs
   I'll save the religious debate about the necessity of stored procedures for another day, but any ORM worth its salt today offers support for Stored Procedures. Some offer better stored proc support than others, but with a good ORM, you can "hydrate" (that's an ORM term that means initialize your model objects with data from your database) objects using stored procs and forego completely ORM generated SQL.
   
   CONCLUSION: Myth busted. Stored Procs are not an excuse for avoiding ORM.
   
   
3. MYTH #3: It's difficult to keep the database and ORM in sync.
   A great myth, and true for simple ORMs like LinqToSql, but absolutely false for ORMs that provide powerful Visual Studio tools. Thanks to improved framework features, like partial classes, and improved tooling, like OpenAccess' wizards, the process of merging database schema changes in to your mapped ORM classes is no longer a frustrating "blow all your customizations away" event. In fact, tools like OpenAccess are powerful enough to go the other direction and merge changes in your classes back in to your database schema! How's that for developer power?
   
   CONCLUSION: Myth busted. It's not hard with modern tools and framework features to keep database and ORM code in-sync.
   
   
4. MYTH #4: I can't optimize an ORM. I'm stuck with its data access decisions.
   This is true for many ORMs, but with powerful ORMs like Telerik's OpenAccess, even this is a myth for the past. Using simple configuration steps, you can give ORMs "hints" that optimize query plans in your application. Generating hundreds of SELECTs when loading a collection of objects? No problem. Specify a fetch plan and those hundreds of statements can be condensed in to one or two powerful SQL statements.
   
   CONCLUSION: Myth busted. True, some ORMs leave you hanging when it comes to optimization (like LinqToSql). But powerful, full-featured ORMs like OpenAccess even make optimization a simple process.
   
   
5. MYTH #5: I don't trust the SQL that an ORM produces.
   The big one! I'd wager this is one of the TOP reasons developers like you avoid ORMs. You don't trust them. You don't trust the SQL they generate and you don't feel like you have a good idea how those simple design-time LINQ queries get expanded to "real SQL" at runtime. Sure, you can fire-up SQL Profiler (or the free AnjLab SQL Profiler Express) and try to see what's coming-out of your app at runtime, but that's inconvenient and can be difficult to analyze. I'd say this is the one myth that continues to trouble today's ORMs. Yes, there are commercial tools that can help with profiling, but out of the box, ORM is largely a "black box."
   
   CONCLUSION: Plausible. This myth presents a challenge that needs a solution. If you're going to stop doing data access by hand, you need to be able to peer-in to the black box and form a trust with your ORM.

GETTING PAST THE 5th MYTH

If lack of SQL transparency- which I think leads to a lack of trust- is one of the biggest barriers to ORM adoption, then it's the problem that should be solved. You should not waste days of your development life writing unnecessary data access code simply because it's too hard to peer-in to the ORM black box and form an understanding of what's happening. What do we need? We need an easy way to see what our ORM is doing. A tool that will help us easily find ways to optimize ORM behavior and establish a close working relationship so that you can focus on application development, and the ORM can focus on moving data.

In Part 2, I'll introduce a simple tool that I've crafted that will help you do exactly that for OpenAccess ORM. In the mean time, let's all agree to stop wasting time, get past our 1999 data access patterns, dispel the myths, and give ORM a try. And since OpenAccess ORM is FREE, why not start today?!

Troubleshooting OpenAccess ORM VEnhance errors

I'm working on what I promise will be a very cool and useful tool/demo for OpenAccess ORM (more on that very soon), and in the process I was reminded of some of the challenges that can pop-up when you start manually "enhancing" OpenAccess-enabled assemblies. Manual enhancing is something you usually do when your project configuration and build steps require maximum control, or when you're trying to use specific versions of the enhancer (VEnhance.exe) with your code. In other words, it's not something faced by every project, and new OpenAccess projects using the new DataContext are event less likely to require manual VEnhance steps.

Still, if you prefer the pre-visual designer approach to OpenAccess, or if you're maintaining code that uses a specific VEnhance version, here are a few quick tips that should help you quick resolve any build-time VEnhance crashes:

1. VEnhance Config: If you're working with .NET 4, a common cause of VEnhance crashes is failure to include the "venhance.exe.config" file in the same directory as the "venhance.exe" executable. This simple config file is needed with .NET 4 to tell the enhancer to use use Framework v4 assemblies when enhancing your code. The contents of the config file are simply:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
  <supportedRuntime version="v4.0"/>
</startup>
</configuration>

2. VEnhance Version: Another common mistake is mis-matching VEnhance versions. That is, using a VEnhance version that is different from the version of the OpenAccess assemblies you're referencing. With the latest VEnhance versions, you can actually use a newer VEnhance.exe with older versions of OpenAccess, so just make sure you're using the latest VEnhance executable. If you find yourself in doubt, though, it can't hurt to make sure both your referenced assemblies and VEnhance version match.
3. Supporting DLLs: The VEnhance tool needs a few external assemblies to do its magic, so make sure they are accessible by the executable (usually best kept in the same directory). If you are copying VEnhance.exe to a project-relative location (good practice for creating "upgrade proof" projects), don't forget to bring these files along: Telerik.OpenAccess.SDK.dll, (and in newer OA versions) Mono.Cecil.dll, and Mono.Cecil.Pdb.dll
4. Manually Run VEnhance: Finally, if after checking your VEnhance version and making sure the necessary config file is in-place, you can always run VEnhance manually. The advantage to doing this instead of using Visual Studio post-build events is that you tend to get much more descriptive errors that help with troubleshooting (versus the totally unhelpful crash message pictured above). To manually enhance:
1. In Visual Studio, select your OpenAccess-enabled project and set the project "Enhancing" attribute to "False" (disables IDE integration "auto" enhancing)
2. Build your project (should build and do no OpenAccess enhancing)
3. Open a command prompt in the directory containing "venhance.exe"
4. Run the command "venhance <path to your compiled DLL>" (In newer versions of VEnhance.exe, it will be: venhance -assembly:"<path to dll>"
5. Inspect the command prompt output for runtime errors or SUCCESS!

There are other options you can use with manual enhancing, too, like the "-verbose+" command combined with "-verboseMode:4" to see detailed output in the command window about what VEnhance is doing. If nothing else has solved your problem, this technique should at least tell you what's wrong.

Don't get stuck or frustrated with useless VEnhance Windows crash dialogs. Try these troubleshooting steps and get back on the road to using one of the most powerful and enjoyable ORMs available for .NET development!

OpenAccess ORM Advanced Q & A, with Stephen Forte

We know that there are still a lot of good questions out there about Telerik's OpenAccess ORM. In fact, you asked a lot of those good questions during our Q2 2009 Release Week Webinar for OpenAccess. To help provide some answers and to introduce you to some of the smart people working on OpenAccess ORM, we recorded an "Interview with the Telerik Experts" featuring Jan Blessenohl, Product Lead for OpenAccess, and Stephen Forte, Telerik Chief Strategy Officer and Microsoft RD. This interview-style Q&A covers a range of questions including:

• How mature is OpenAccess? What version is the product on now?
• How hard is it to switch database providers with OpenAccess? Is there support coming for databases like VistaDB?
• How do you use OpenAccess with web services and Silverlight?
• How does OpenAccess compare to Entity Framework? What are the main advantages / disadvantages?
• What is the future of LINQ and how does that impact OpenAccess?
• What is the future of OpenAccess ORM?

In addition, Jan does a couple of demos with the latest version of OpenAccess showing you things like reverse mapping ("Schema First") and the new Generic Data Access API. We hope you enjoy the answers, demos, and interview format. If you like this format, let us know and we will work on creating more "Expert Interviews" for Telerik TV. Watch video in full resolution on Telerik TV [50:23]

OpenAccess Q3 2008 SP3 released today

For those of you already working with Telerik's cool new OpenAccess ORM tool, there is a new service pack that dropped today that you definitely want to check out. The service pack- officially dubbed Q3 2008 SP3 (or 2008.03.1327.2 by the version number)- packs tons of fixes and improvements in to both the OpenAccess run-time and design-time experience. Among my favorite improvements is the new support for the LINQ Count method, which now allows you use .Count in your LINQ queries and have it it executed on the database server for optimum performance. For a complete run-down on what's fixed, check out the official release notes. For those of you not using OpenAccess ORM, what are you waiting for? I recently built the entire Telerik TV portal using OpenAccess ORM Forward Mapping, and speaking as a developer, the experience was great. It saved me a ton of time (and code), and made it very easy to build a complex site in my spare time in a matter of days. If you're using LinqToSql today and want something that gives you that same "quick start" experience, but then also has the power to perform when you need to take more control, give OpenAccess a try. With a free version for free databases, what do you have to lose?

Telerik Watch Minute: OpenAcess ORM Fetch Plans

In this third and final (for PDC) interview with Jan Blessenohl (OpenAcess ORM Team Lead), I ask Jan to show us how we can optimize the SQL queries OpenAcess produces. One feature that many ORMs provide, including OpenAcess, is Lazy Loading- or the concept of only loading objects when you need them in code. This is great for many scenarios as it saves you from loading more data than you need, but there are scenarios when you want to tell your ORM to load more agressively (for instance, when displaying data in a grid). In this video, Jan demonstrates how to create OpenAcess ORM Fetch Plans that enable us to easily optimize the SQL queries OpenAcess generates without requiring us to change the actual code of our query or object at all! So if you already understand the basics of forward mapping and reverse engineering, this video will help you go to the next step of optimization.

Telerik Watch Minute: OpenAccess ORM reverse engineering

Here's another great introductory video to Telerik's new OpenAcess ORM product. In this special edition of Telerik Watch Minute, I sit down with Jan Blessenohl (OpenAcess ORM Team Lead) and take a look at how you can use OpenAcess ORM to reverse engineer an existing database in to business objects (vs. the forward mapping approach we looked at last time). In this 13 minute video, Jan shows us everything from creating a new project to reverse engineering your database to merging database changes to existing objects to using your reverse engineered objects in an ASP.NET application. It's a great primer on the subject so I hope you enjoy! [Production Note: I regret that I have to keep making these "production notes." I guess it's more difficult than I anticipated to staff a booth, attend sessions, and shoot videos at PDC. As such, this video was recorded with a heavy "light filter," producing a grainy looking, dark video. Apologies. The next video fixes the problem and I promise I'll try to ensure these mistakes don't happen at future events!]

Telerik Watch Minute: Interview with Jan Blessenohl, OpenAccess ORM

While at PDC 2008, I had the fun opportunity to sit down with some of the Telerik product team guys and put them on camera for you to meet. First up for your viewing pleasure is OpenAccess ORM Team Lead, Jan Blessenhol. In this short(ish) 20 minute interview, Jan explains to us what OpenAccess ORM is, why it's unique, and then does a live demo showing us how OpenAccess' basic Forward Mapping features work. If you're interested in knowing more about Telerik's new ORM product, this is a great place to start. And I also need to make a quick production note. We had a couple of "glitches" in this recording that I reget. First, the audio for much of the video is much poorer quality than it should be because I forgot to record the microphone in my hand. Second, the lighting was bad and I forgot to pull-out the 'ol camera light. Finally, the HDD recorder battery died during the shoot so we had to "append" the ending- as such, it looks a little different that the rest of the video. I apologize for all the tech trouble and hope you can still enjoy the video. Expect better quality next time!