bistro is an alternative implementation of the classic Model-View-Controller design pattern, using the Velocity templating language as the main rendering engine. Bistro combines concepts from REST and AOP to build a highly scalable application development framework. This document is intended to give you an overview of the bistro framework, and direction on where to get more information.
The bistro stack
bistro is the controller layer in a standard MVC implementation. The whole stack consists of an extended Velocity templating engine, the bistro controller framework and the wfs orm model layer and assorted goodies.
The almost-0-configuration "hello world"
Aiming to get application development going, all configuration options in bistro have defaults, and can be omitted. Want to get started? Keep readin'. Want to tweak? Read the Reference Guide
To get going, all you have to do is plug in the bistro module (sorry, folks, to get extension-less URLs working with ASP.NET, you gotta play nice with .net 3.5, so have either mono 2.4, IIS7, or the Visual Studio 2008 Development Server). For running Bistro applications on IIS 5.1/6.0 see Running Bistro Applications on IIS 5.1 or IIS 6.0.
<add name="BistroModule" preCondition="" type="Bistro.NVelocityIntegration.Http.NVelocityModule, Bistro.NVelocityIntegration" />
<add name="BistroHandler" path="*.bistro" verb="*" type="Bistro.NVelocityIntegration.Http.NVelocityHandlerFactory" resourceType="Unspecified" />
and start writing code!
public class Default : AbstractController
protected string message;
public override void DoProcessRequest(IExecutionContext context)
message = "hello world!";
Following the defaults concept, this controller will respond to a request /Test/Default. Now, there's just one thing missing - a template, but that's easy enough:
<title>my first bistro app!!!!!1!!ONE!</title>
But we're just scratching the surface. Here are some of the other things you can do
Think resources and actions, not URLs and controllers
We like REST, and we don't care who knows it. We like it so much, that we think that when you build an application, you should think of it as a collection of resources that are consumed by the browser. The application exposes an interface that can be invoked through GET or POST HTTP methods, each URL it understands being a distinct resource. That puts more control in the browser, and less navigational complexity and interdependence in the server.
Define smart URLs and small controllers
Use Bind attributes to specify what incoming requests should trigger what controllers. We don't map different actions to different methods of a single class because we think that each action shouldn't be tightly coupled with another. That way, if you want to do a /search and also want to /search/bytag/stuff, your bytag controller does need to know how to perform a search, and your search controller does need to know how to figure out what tags you want to search by.
Build your security policy where you use it
Using a deny-first security policy and security controllers, you can specify security policy alongside the code that will need protecting, not in an external config file.
Build loosely coupled chains of controllers
Since a single request can be processed by multiple controllers, we have a sophisticated, but easy to use system of specifying the order things run in. Session and request scoping attributes along with dependency definitions on fields tell the system what the implicit interdependencies are, without tightly coupling controllers. This way, the runtime knows what things need to happen in order, and wings it on the rest.
As a result, the system can dynamically parallelize request execution, and even split request execution among multiple physical hosts.