BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Jasper: ORM without Code Generators or Configuration Files

Jasper: ORM without Code Generators or Configuration Files

Bookmarks

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
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.

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

Community comments

  • nice to see .NET community catching up :)

    by Floyd Marinescu,

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

  • Configuration Files

    by Geoffrey Wiseman,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

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

BT