Paul Gielens:ThoughtsService

Actually, Jasper always works over the conceptual model (EDM).  It essentially has three models:

1)  Based on database schema (tables, columns, PK/ FK relationships, etc) a Default EDM and mapping is generated.  This uses a default naming service to handle plurization (Orders table -> Order type)

2)  Same as 1, but use plugs in a custom naming service.

3)  User specified EDM and mapping.  

In all three cases, the type generation and query/ CUD translation is completely independent of whether a default EDM was generated or specified.

This is covered a bit in the overview document, I will try to get a blog post up about it also.

Subsonic is also an orm that doesnt require the source class files to be generated. The team has used a buildprovider which emits the class information dynamically without the need for source classes.

Jasper looks cool, but it seems that the new things comming out are taking the coding out of programming.

Things are more efficient when they're all custom built by the coder. Have all of these things at our finger tips will allow us to creat applications very quickly, but at what cost?

"Things are more efficient when they're all custom built by the coder." is a big, fat lie.

A couple of comments on the comments...

The goal of Project Jasper is not to take the coding out of programming, but allow the programmer to only write the code the is specific to the application.  In other words, we have gone to the extreme of trying to remove almost all plumbing code but not application specific business logic.  If you watch our "Data Access City" demo from Mix07 (http://sessions.visitmix.com/default.asp?event=1011&session=2012&pid=DEV18&disc=&id=1527&year=2007&search=DEV18), there is quite a bit of code - but the code is all very specific to the application - stuff the framework could never do without introducing some alternative way for the developer to specify “code”.  We believe developers are comfortable writing code, and have no goal of introducing a code free framework.   We have a lot of work to do, but one of our eventual goals is to make programming against the Jasper framework similar to using a DSL.   The framework provides the model (either generated by default or specified by the developed), the corresponding runtime clr types, and a default controller for coordinating model view interaction – the developer provides app specific code representing the business logic specific for the app’s domain.

My other comment is that the Jasper framework is intended to be a high level API.  There will definitely be cases where the developer could do things more efficiently if they use the lower level APIs.  In my opinion, this is true of almost anything when one increases the level of abstraction.  In other words, we are explicitly making the decision to significantly increase developer productivity while sacrificing some code efficiency.  Because Jasper is built on the ADO.NET Entity framework, we have a huge advantage that the developer could always drop down to the lower level API – even in an application that largely uses Jasper.  That said, there are a couple of huge challenges here:  1)  Make sure the Jasper framework’s perf/ scaliblity is good enough for production deployment for the targeted scenarios and 2) Get the layering right with the low level APIs.  In other words, we have a lot of work to do.

Pingback from  Some comments about comments and other ramblings about Project Jasper | All you can LINQ

Pingback from  All you can LINQ » Some comments about comments and other ramblings about Project Jasper