Jasper: ORM without Code Generators or Configuration Files
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.
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.
nice to see .NET community catching up :)
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
(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
How many seconds using Google would it have taken MS to work this out?