Re: Web frameworks - separating UI from logic

On Fri, 23 Feb 2007, Brian Candler wrote:

> 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 (*).

This makes sense, though I don't know that you need an RPC layer in there.

> 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.

MVC is a reinvigorated buzzword when it comes to web applications, even 
when what a web application is implementing is something a bit different 
from the classical definition of MVC.  MVC is just a more marketing 
friendly term than what is really important -- a separation of concerns. 
So don't sweat the details of what is or isn't MVC too much.  What you 
really want is just a logical separation of concerns.

> 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.

You'll find that for most simple web apps, this level of separation is the 
common case.  For that majority of applications, it is a sweet spot 
between having enough separation to make code management easier and 
cleaner, while not having so much separation as to introduce additional 
complexities.  This doesn't preclude having greater separation, though.

> It looks like I'd hardly be using any of Rails - just the HTML templating
> and perhaps session tracking. Maybe then a more lightweight framework would
> be better suited? (**)
>
> Perhaps there's a simple framework I can use which will avoid having to
> re-write this from scratch?

There are a few you could consider.  Nitro has been around for a while. 
It is lighter weight than Rails, for sure, and is a capable system.  It's 
currently undergoing a massive rewrite which should make the Nitro world a 
much prettier one, too.  Unfortunately, I have had some serious problems 
getting the latest release, 0.41, to work (at least from a gem 
install) because of a dependency issue.

Camping is a very lightweight framework that you might consider.

Likewise, for a Rails-lite that might be right up your alley, look at 
Merb.  It's designed to be fast and light for things that don't need all 
that Rails has built in.

You might also consider my framework, IOWA.  The 1.0 release of it is now 
imminent (after nearly 5 years, wooo hooo!).  Feel free to drop in on my 
little freenode IRC channel, #iowa, or email me directly 
([e-mail]) if you have any questions.

Now, regarding your overall application design, I don't understand why 
you'd need to implement an RPC server for the application logic, so my 
first impression is that you would be best served by writing a class 
library that encapsulates the application logic.

Once you have that, whether you are writing a web interface or a SOAP 
interface or a command line tool, they all have access to the same 
functionality by using your class library, without the added 
complication/overhead of maintaining an RPC service.


Kirk Haines