Condividi tramite

Some comments about comments and other ramblings about Project Jasper

  • Articolo

Over the last week or so we have been trying to gather information on what developers are saying about Project Jasper. (This, even in the age of rockin’ search engines is a lot harder then one thinks). As part of this, I have seen a handful of interesting comments that I wanted to comment on.

On Paul Gielens blog, in the blog comments for RAD is Making a Comeback with Jasper Ryan Ternier added the following comment:

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

On this point, the Project Jasper team totally agrees with Ryan. The goal of Project Jasper is not to take the coding out of programming, but to allow the developer to concentrate on code for one’s specific problem domain. In other words, one of our primary goals of the Jasper framework is to provide a model centric development experience where a majority of the app’s code is not plumbing code and/ or something the framework can take care of through convention. At a high level, the Jasper framework provides a conceptual model based on the underlying database or specified EDM. From there it also generates data classes dynamically at runtime so the developer can interact with the model in an O/R fashion. We fully expect the customization of these types and the interaction with the model to be code, and actually wouldn’t have it any other way. I don’t think we are there yet, but one of our eventual goals is to make the experience of programming against the Jasper API feel like using a DSL for one’s specific model. To be clear here, this is not our unique idea but based more on where we see the industry is headed.

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 create applications very quickly, but at what cost?

Have to agree with this point also. Any time one decides to use a given framework or API, there is definitely a tradeoff between control and efficiency – both of the developer and the actual code. To be clear, the Jasper framework is a high level API. In other words, we are explicitly making the choice to increase developer productivity while sacrificing developer control and some code efficiency. However, since 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, in my opinion we have three challenges with Project Jasper to make it useable: 1) Make sure the Jasper API is the right abstraction to solve the targeted scenarios 2) Perf and scalability need to be good enough for production deployment of those same targeted scenarios and 3) Get the layering with the lower level APIs correct. IMO, for the first CTP release we have not done a super good job with any of the challenges, but have it on the radar.

There was also an interesting thread on the comments for Mary Jo Foley’s article about Jasper.  One reader added the following:

I see where Microsoft's running with this stuff. The "quick and dirty" quote makes me nervous. Our projects are never of the quick or dirty kind, and more accurately, are usually the 6 month to a year kind. We (my company) don't want to have anything quick and dirty in our applications, we don't want any part of the application to be quick and dirty, simply because eventually one of us has to go back to that project many moons down the road, when the client requests changes, and we're looking at all this quick and dirty code. We want to find the stuff that we can read easily then.

I have two comments for this: 1) For big projects with many developers, Jasper may not be the right tool. At least initially, we are trying to tackle the writing small to medium sized apps against an existing database. i.e. exposing a legacy database via a bunch of web services or a bunch of small form based applications. 2) There may be reasons a framework like Jasper is right for your project, but we never want it to be because the code is not readable or maintainable. Hence, why the project’s motto is “Quick and Clean”. In other words, we don’t want to provide a solution where initial developer productivity is traded for code maintainability down the road.

And finally, there is this entire post which the project team found very entertaining.

My only comment on this is that we would be lying if we told you weren’t impressed by the work being done by some of the web frameworks out there, but we also believe we have a number of features that make our solution unique: Linq support, support for multiple dynamic languages (IronPython, VB, IronRuby, managed Javascript), completely dynamic data class generation, a ASP.NET story that is not revolutionary, and rich mapping support.

Comments

  • Anonymous
    May 11, 2007
    ha ha. thanks for reading! (i feel a little embarrased though ;-))one question i've got -- is there a connection between blinq and jasper?
  • Anonymous
    May 12, 2007
    secretGeek has a valid point about the SQL Server-only limitation of Jasper.If Microsoft intends to live up to its committment that a primary feature of the Entity Framework is "The ability to query relational stores other than the Microsoft SQL Server family of products" it behooves the ADO.NET team to extend this capability to Entity Framework derivatives, such as Jasper and Astoria (which also has an SQL Server 2005 requirement for the toolkit). Microsoft must clarify that the SQL Server 2005-only limitation applies only to the early "incubator project" releases and not to the final release, if there is one. Failing that is "crying wolf"—no developer or RDBMS vendor will believe that the Entity Framework will be RDBMS-agnostic when Microsoft says Katmai will deliver the Entity Data Platform.--rjSee the 5/12/2007 update to http://oakleafblog.blogspot.com/2007/05/using-entity-framework-with-ironpython.html
  • Anonymous
    May 12, 2007
    secretGeek,My understanding is that Blinq is based on LINQ for SQL (it uses SqlMetal.exe), not the Entity Framework.Not much has been hear about Blinq since it's mid-2006 release as a prototype that used the May 2006 LINQ CTP. It appears from the Blinq forum that the prototype hasn't been updated for Orcas Beta 1's LINQ implementation.--rj
  • Anonymous
    May 12, 2007
    okay -- i've just researched this a little further.So it seems that blinq is from the ASP.net team while Jasper is from the ADO.net team. Different beginning but a common goal. (I had wrongly assumed that Jasper was a rewrite of Blinq).A nice paragraph tying the two together is written here:http://pather.net/shyam/ViewPost.aspx?PostId=7(under the heading -- "ASP.NET Dynamic Data Controls")cheerslb
  • Anonymous
    May 14, 2007
    The comment has been removed
  • Anonymous
    May 23, 2007
    Integrating Dynamic Data Controls with Jasper appeals to me because BLINQ was based on LINQ to SQL. If BLINQ morphed to DDCs, this would indicate that the DDCs are based on LINQ to SQL, too. Assuming that Jasper becomes RDBMS-agnostic, it would provide RDBMS independence to the DDCs and, presumably, greater O/RM flexibility.--rj
  • Anonymous
    June 03, 2007
    When will Jasper Final be released? Anticipating~~~~
  • Anonymous
    June 04, 2007
    No RTM release plan yet.  We are currently planning for another CTP release towards the end of the year.