# Web frameworks - separating UI from logic

**URL:** <https://www.ruby-forum.com/t/web-frameworks-separating-ui-from-logic/86481>\
**Category:** Ruby\
**Created:** [February 22, 2007, 5:37pm UTC](https://www.ruby-forum.com/t/web-frameworks-separating-ui-from-logic/86481 "2007-02-22T17:37:15Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![stickstone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/6f9a4e/32.png) [@stickstone](https://www.ruby-forum.com/u/stickstone)\
**Post date:** [February 22, 2007, 5:37pm UTC](https://www.ruby-forum.com/t/web-frameworks-separating-ui-from-logic/86481/1 "2007-02-22T17:37:15Z")

</div>

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:

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

I expect I can write my own application logic server, and use Rails as a  
front-end to submit RPC requests to it. This means that the controllers  
would do very little though, just:

- bundle up the paramters and submit an RPC request for an action
- look at the response (success or fail)
- submit an RPC request to get model state
- generate a suitable HTML page response

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? (\*\*)

I wrote a tiered application along these lines a few years ago for a  
different employer. I ended up writing a framework to handle the FCGI  
main  
loop; compile Amrita templates on demand and cache them; and handle  
unexpected exceptions, displaying a suitable page back to the browser.

Perhaps there’s a simple framework I can use which will avoid having to  
re-write this from scratch?

Thanks for your ideas.

Regards,

Brian.

(\*) This could be quite complex logic. For example, “create order for  
customer” might perform a bunch of validation, do a credit check in some  
circumstances, add an order line into a database, send a message to a  
billing system, and send messages to service provisioning platforms.

(\*\*) I can imagine cases where it might make sense not to stick rigidly  
to  
the tiered approach. As mentioned above, maybe the UI could be allowed  
to  
read the model state directly; this suggests

```
    HTML RPC SQL
 <--------> user ---------> application <--------> database
          interface logic |
             ^ .
              ` . . . . . . . . . . . . . . . . . .
                       read-only query path

```

In that case, if the application logic was already using ActiveRecord as  
its  
model, then Rails would probably be a good choice for the UI. You’d  
share  
the ActiveRecord model definition, and give the UI read-only DB  
credentials.

However in my case I may need to force all data accesses via the  
“application logic” layer, in particular to provide a central point of  
enforcing access control policies - i.e. who can read what.

I can also see that the UI might legitimately need R/W access to a  
database  
for its own private purposes (for example, the UI could be responsible  
for  
assembling a shopping cart, before submitting a completed order). In  
this  
case the database is just a UI scratchpad, entirely separate from the  
business model. Therefore, you might want something like ActiveRecord  
available even with the tiered approach.

---

<div class="post-metadata">

**Author:** ![stickstone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/6f9a4e/32.png) [@stickstone](https://www.ruby-forum.com/u/stickstone)\
**Post date:** [February 22, 2007, 6:09pm UTC](https://www.ruby-forum.com/t/web-frameworks-separating-ui-from-logic/86481/2 "2007-02-22T18:09:22Z")

</div>

On Fri, 23 Feb 2007, Brian C. wrote:

> ```
> 1 |
> 
> ```
> 
> In ‘MVC’ terminology, I think the “application logic” box is a Controller  
> 2. Validate the request and perform any database updates directly  
> 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

---

<div class="post-metadata">

**Author:** ![stickstone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/6f9a4e/32.png) [@stickstone](https://www.ruby-forum.com/u/stickstone)\
**Post date:** [February 23, 2007, 3:50pm UTC](https://www.ruby-forum.com/t/web-frameworks-separating-ui-from-logic/86481/3 "2007-02-23T15:50:55Z")

</div>

On Fri, 23 Feb 2007, Brian C. wrote:

> ```
> 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  
(removed\_email\_address@domain.invalid) 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 H.

---

<div class="post-metadata">

**Author:** ![stickstone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/6f9a4e/32.png) [@stickstone](https://www.ruby-forum.com/u/stickstone)\
**Post date:** [February 23, 2007, 4:39pm UTC](https://www.ruby-forum.com/t/web-frameworks-separating-ui-from-logic/86481/4 "2007-02-23T16:39:05Z")

</div>

On Fri, Feb 23, 2007 at 11:50:17PM +0900, removed\_email\_address@domain.invalid wrote:

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

OK.

Perhaps what confused me about Rails is that there seem to be a lot of  
default controls - the CRUD stuff - which act on a single table at a  
time.

If I could hide those sort of controls, and expose only higher-level  
controls to the user which perform business logic, that would be part of  
my  
problem solved.

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.

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

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 🙂

Thanks,

Brian.

---

<div class="post-metadata">

**Author:** ![stickstone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/6f9a4e/32.png) [@stickstone](https://www.ruby-forum.com/u/stickstone)\
**Post date:** [February 23, 2007, 5:36pm UTC](https://www.ruby-forum.com/t/web-frameworks-separating-ui-from-logic/86481/5 "2007-02-23T17:36:18Z")

</div>

On Sat, 24 Feb 2007, Brian C. 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 H.