From: ara.t.howard@...
Date: 2007-02-23T02:08:15+09:00
Subject: Re: Web frameworks - separating UI from logic

On Fri, 23 Feb 2007, Brian Candler wrote:

> I'm starting to look again at available web application frameworks for Ruby
> - it's been a few years since I last did. What I'm looking for is to be able
> structure my application like this:
>
>        HTTP+
>        HTML            RPC(*)                  SQL
>     <--------> user <--------> application <--------> database
>              interface            logic
>
> (*) e.g. DRb, or just direct invocation of a separate object
>
> The idea here is to be able to bolt multiple front-ends onto the same
> application logic. For example, you might start by having a web form for
> entering new customer orders, but then you could add a SOAP interface so
> they can be submitted automatically, or a batch-upload interface which
> accepts CSV files.
>
>        HTTP+
>        HTML             RPC                    SQL
>     <--------> user <--------> application <--------> database
>              interface      ->    logic
>                 1           |
>        SOAP                 |
>     <--------> user <--------
>              interface
>                 2
>
> The important thing is that the business logic for (say) validating orders,
> or performing a series of actions in response to submission of a valid
> order, exists exactly once and so is the same regardless of how the request
> came in (*).
>
> In 'MVC' terminology, I think the "application logic" box is a Controller
> with a Model sitting behind it. It will also need to provide an interface to
> query the state of the Model, unless the Model directly exposes a read-only
> view to the UIs.
>
> My first port of call for looking at modern frameworks is Rails. Looking
> through the Rails tutorials, I get the impression that a Rails "controller"
> is responsible for three things:
>
> 1. Parse the HTTP request, e.g. extract relevant params()
>
> 2. Validate the request and perform any database updates directly
>
> 3. Decide which view to send back to the browser (which in turn also
>   queries the database directly)
>
> Is that a fair summary?
>
> Would it also be true to say that in Rails, the de-facto model is just a
> bunch of database tables, with a separate ActiveRecord facade sitting in
> front of each table? For example, if a particular action requires four
> tables to be updated, would the controller typically get four ActiveRecords,
> modify them and write them all back? If so, this seems to bundle the 'user
> interface' and 'application logic' parts together more closely than I'd
> like.

hi brian-

i think you can flex on #3 above to get what you want.  basically, write your
entire logic stack, in it's entirety, as Controller private methods.  these
private methods will deal with ruby values only - no html, xml, etc..

then you can test this.  when that's complete, you can bolt on views as html,
xml, soap, etc.  in otherwords, you can simply add on layer of abstraction via
method calls inside your controller, another controller class, etc.  in
otherwords simply defer parsing input from params, sessions, etc and also
avoid generating view components.  simply write all logic with ruby values
in/out.

in the end you'll have two tiers of controllers

   logic-centric controllers

     1) perform logic based on ruby arguments.  returns ruby values.

   view-centric controllers

     1) parse params, etc

     2) use a logic-controller

     3) decide what output to send

of course there are other ways to slice this, such as a very thick model - but
that's not very mvc.

regards.


-a
-- 
be kind whenever possible... it is always possible.
- the dalai lama