Ovirt devel - Apr 2009 - Refactoring controllers for QMF and profit

For the QMF API, we need to reorganize the code that is in the Rails
controllers currently. The basic issue is that Rails controllers
fundamentally need a web request to do their thing, but since QMF is not
web based, there is none (and the possibility of faking a web request
would get us too deep into Rails internals to be supportable)

The Rails controllers serve two purposes: (1) presentation logic and (2)
business logic. Of course, we do not want to replicate business logic in
the QMF API, instead we want to make sure that both the WUI and the QMF
API use the same code for their business logic. That means we need to
leave the presentation logic in the controllers and move the business
logic to somewhere else.

To make this more concrete, good examples of business logic are the
permission checks that accompany each action in the WUI, or the work
needed to create a new VM - business logic in general has (a) a notion
of a current user and (b) touches multiple model objects at once. In the
Java world, this new layer is known as 'stateless session beans'.

What I am proposing here is a general strategy of what this new layer
will look like and (most importantly) what it will be called - since the
word 'Session' is so terribly overloaded, I am going with the marginally
less overloaded word 'Service' (and am willing to pay the person who
comes up with a better name $2.55)

Architecturally, the layers in the combined WUI/QMF system would look
like this:

                     ActiveRecord models
                            |
                     service modules
                        /         \
                       /           \
           QMF controller/view   ActionController
                                      |
                              WUI view (templates etc.)

As a side effect, the code will be written in a way that would let us
service QMF requests and web requests from the same process - whether
we'd ever actually deploy like that remains to be seen, and we might
very well wind up with deployments where one of the two branches is
always turned off through some config option.

The meat of the service layer will happen in modules, which has the
advantage that we do not use the inheritance slot in users of the
service layer (so that Rails controllers can still inherit in the usual
fashion); by including service modules in the classes that use them, we
can still use instance variables for various purposes, just as we do in
the Rails controllers today.

To make all that a little concrete, I sketched out what that would look
like for the code around VM creation; attached is that sketch - it has
all the Ruby code (which is definitely not working) in one file.

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: service.rb
Type: application/x-ruby
Size: 8580 bytes
Desc: not available
URL:
<http://listman.redhat.com/archives/ovirt-devel/attachments/20090410/07cc7a40/attachment.bin>