From: khaines@...
Date: 2007-02-24T01:36:07+09:00
Subject: Re: Web frameworks - separating UI from logic

On Sat, 24 Feb 2007, Brian Candler wrote:

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

> The other part is ensuring that my application isn't tied only to
> interactive HTTP use. But then I should be able to build (say) a SOAP facade
> which maps onto the same controls, yes?
>
> Then all I have to do is ensure that no database updates are possible except
> via these controllers - for example, by keeping the database write password
> secret.

I do think that the easiest way to do this is to put all of your common 
code into a class lib, including everything that interacts with your 
backend database.  Then, whether you use Rails or something else to create 
your HTTP interface, you guarantee that nothing goes directly to your 
database simply by forcing all interaction to go through your API, yes.

> Well, "RPC" was also assuming that by the time this was deployed, there
> would need to be multiple application servers for load-sharing and
> resilience. But equally, "RPC" could just be direct object invocation - i.e.
> LPC :-)

I understand.  Makes sense.

I'm not going to steer you specifically away from Rails or towards my 
framework or someone else's, specifically.  But I do think you are 
probably right in thinking that a lot of what Rails provides regarding 
interaction with your model you won't be using, so Rails may indeed be 
heavier than what you need.  If I were you I'd pick a few frameworks and 
ask some questions about them.  The answers will probably steer you 
towards something that matches your needs and your way of thinking about 
web applications.


Kirk Haines