Some thoughts on application interaction. This is your application logic and controllers.
Applications are interfaces to your business logic. They can be HTTP (web) applications, command line clients, bare bones TCP, ZeroMQ or whatever!
Let's start with a sinatra application.
Okay so I've provided you with a hello world for sinatra and minimal business logic. No data or view logic. However I've already talked that malarkey. This example is an application. It is the interface for HTTP that business logic requires.
It is however only suitable for limited life shelf applications or tiny ones. We need to introduce the other part of interaction now, controllers.
So now we've added a controller to contain our (albeit over simplistic) business logic. This abstraction allows us to separate our application interface, in this case sinatra routing, and our business logic execution.
Let's go over two points:
- applications serve your business logic to users
- controllers provide business logic to applications
Ahhh, separations of concerns.
Applications know about receiving requests and serving responses. They don't care about business logic implementation. It never need know about your mappers, data and view models, etc. All an application needs to do is pass request values into a controller and receive a response back.
Controllers talk to your business logic and almalgamate it for
application consumption. A controller might have a
method for GET requests in HTTP, or
#action for POST
requests but these method names should be protocol and thus
application agnostic. A view can be served over many protocols
and so can actions be received.
This separation then gives you the flexibility to swap out applications. Start with Sinatra, move to Rails, realise it's a piece of junk, move to Padrino and then settle on Sinatra with some Padrino components. Your controllers should not need to be changed. Your application layer should normalise requests into hashes so that your controllers can remain ignorant of them.
Think of the additional power this provides. Being able to replace your application layer with anything. Say a test layer? You can run your entire application stack from tests without requiring a framework at all! Never again will you have to put up with slow rails integration tests.
With this abstraction of interaction you will be able to grow your entire application without ever being stuck to a particular vendor. I'm not against using rails. I'm against being stuck to it. This pattern described here will keep you free of those constraints.
I use this equation to describe the interaction layer.
I = A + C