ExpressoFramework

From SPA Wiki

Jump to: navigation, search

The presentation foils can be found on my web site at http://www.jbridge.co.uk/expresso.html

There was some brief discussion in the session about essential qualities for MVC frameworks targeting relational databases.

The group identified the following qualities for the View/Controller layers:

  • Flexible views (with regard to layout for different target devices)
  • Workflow support in the controller.
  • Security.
  • User Session Management.
  • Transactions.

And the following for the Model layer:

  • Flexible mappings - especially the ability to "meet in the middle" (have an existing database and existing object model, and be able to marry the two).
  • Support for incremental change.
  • Failover.
  • Transaction Support.
  • Event firing (change to model informs other layers).
  • Implicit persistence.
  • An abstract query language.

I briefly fed back how Expresso provided for these requirements (if at all) - here is a summary:

  • Flexible views (with regard to layout for different target devices) - theoretical support. The controller layer talks in abstract concepts ("Inputs", "Outputs") theoretically aimed at any view layer. However, the only view provided is JSP/tag-based. That said, the news groups talk about other styles of client interfacing to Expresso controllers.
  • Workflow support in the controller - extension of Struts actions. Screenflow support perhaps rather than true workflow.
  • Security - Expresso does provide its own fairly sophisticated security layer.
  • User Session Management - Pretty good (includes "console" to see who is logged on to applications).
  • Transactions - basic commit / rollback support.
  • Flexible mappings - especially the ability to "meet in the middle" (have an existing database and existing object model, and be able to marry the two) - Expresso not so hot on this. Can generate object model from schema, or schema from Expresso-fied object model. Meet in the middle - no.
  • Support for incremental change - not particularly. Change to schema usually requires change or regeneration of Expresso DBObjects.
  • Failover - not really part of Expresso. Expresso needs to run within an application server (Tomcat, WebSphere, whatever) - so look to the container to provide the failover.
  • Transaction Support - mentioned already.
  • Event firing (change to model informs other layers) - no.
  • Implicit persistence - sorry, not sure what exactly was meant by this - my fault for not writing up feedback sooner!
  • An abstract query language - yes, that is an Expresso strength; you can change the database underneath, but the Java to access it remains standard. It would be nicer if it complied to an existing standard like JDO. But then, JDO wasn't mature enough when Expresso was first written...

DavidBridgewater (August 2003)