BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Jasper: ORM without Code Generators or Configuration Files

| by Jonathan Allen Follow 6 Followers on May 04, 2007. Estimated reading time: 1 minute |

Jasper is Microsoft's new ORM project designed for rapid application development. And unlike earlier Microsoft projects, this one does not require code generators. The goal? To "make the experience of developing quick and dirty database apps one that is truly quick and clean."

Traditionally Object-Relational Mapping comes in three flavors. First is the hand-rolled code, where-in each data class is created manually without any help from the IDE. The second, which is very popular with Microsoft, is code generators. From early.NET technologies like typed datasets to LINQ, code generators create the domain objects that are mapped to the database.

In the Java and Open Source camps, configuration files are quite popular. These files, often written in XML, define what the objects look like at run time. While the tools are different, the end results are very similar to the code generators mentioned above.

Microsoft Codename “Jasper” is a set of components aimed at fulfilling the need for a rapid and iterative development experience for data. With Jasper, you are able to just point at a database and immediately begin coding against its data using intuitive, domain-specific data classes. No configuration and no source code generation are required. Jasper works with existing application frameworks (including ASP.NET, WinForms, and WPF) and existing, real-world databases.

In real terms, this means the data objects are generated at run time based on the database schema discovered. Ideally, this will give you most of the rich experience you would expect from LINQ without the hassles of keeping generated code in sync.

For the initial CTP, the target languages are Visual Basic 9 and IronPython 1.1. C# will not be supported because it lacks the late binding features needed to work with the runtime generated classes.

The dynamic features offered by the DLR are being considered for Jasper. Theoretically, they will allow business rules to be attached to the dynamically generated data objects at run time in the form of additional methods and properties.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

nice to see .NET community catching up :) by Floyd Marinescu

It's nice to see the .NET community starting to catch up in the area of ORM.

Configuration Files by Geoffrey Wiseman

While configuration files certainly have their downsides (see Convention over Configuration), I would argue that they're not very similar to code generation, at least, not for my purposes.

With Hibernate's configuration files, I can write objects and database tables that aren't very similar to each other. This flexibility allows the database and object model to differ in ways that some people argue is important. (I'm not always sure the difference is important, but, then, I come at it from an object point of view).

Further, configuration files don't require explicit tool support or an extra step in the build process -- code generation usually requires one or the other. That's mostly a matter of infrastructure aesthetics, but it matters to some.

The late-binding aspects of the languages is important; it's that kind of flexibility that a dynamic language can give you, as long as you're willing to accept the costs. This would be difficult to do with, say, a Java ORM (although I could argue that there are benefits to that approach; it's a tradeoff, like most technology differences).

Re: Configuration Files by Gavin King

Right, a mapping document is not actually a "configuration". To me the word implies something that changes between different deployments of a system, which O/R mappings almost never do. Rather, the O/R mapping

(1) bridges the different modelling languages of the relational and object paradigms
(2) insulates new application code (specifically, the business logic) from "mistakes" in naming and modeling that exist in the legacy data model

Or course, the field of O/R mapping moved on from external XML "configuration" files several years ago, and the favored approach is now the use of annotations to embed the mapping information in the domain class. This is a great compromise solution that sacrifices neither flexibility nor productivity.

Oh, and it is well worth noticing that the most popular O/R mapping annotation language (EJB3 persistence / JPA) embraced and championed the idea of "configuration by exception" from the beginning, years before the fashionable crowd started huffing and puffing about "configuration by convention", a different name for the same thing.

Duplicated Project Names by Andrew Swan

I'm no anti-MS campaigner, but there's a special place in hell for people that reuse existing project names; see:

jasperforge.org/sf/projects/jasperreports

How many seconds using Google would it have taken MS to work this out?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT