NAME
dao
SYNOPSIS
a sa-weet-ass library for structuring rails applications using the 'data
access object' design pattern. dao consists of two main data access
objects, *api* objects and *conducer* objects. conducers combine the
presenter pattern with the conductor pattern.
API
class Api < Dao::Api
call('/posts') do
get do
data[:posts] = Post.all.map{|post| post.attributes}
end
post do
post = Post.new(params[:post])
if post.save
data[:post] = post.attributes
else
status 420
end
end
end
end
CONDUCER
# TODO
wikipedia has this to say about dao in general
"
In computer software, a data access object (DAO) is an object that
provides an abstract interface to some type of database or persistence
mechanism, providing some specific operations without exposing details
of the database. It provides a mapping from application calls to the
persistence layer. This isolation separates the concerns of what data
accesses the application needs, in terms of domain-specific objects and
data types (the public interface of the DAO), and how these needs can be
satisfied with a specific DBMS, database schema, etc. (the
implementation of the DAO).
"
- http://en.wikipedia.org/wiki/Data_access_object
and
"
Models are not data access objects...
"
- http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
DESCRITPION
API
applications that are written on dao look like this in ruby
result = api.call('/posts/new', params)
and like this in javascript
result = api.call('/posts/new', params)
in command-line applications they look like this
result = api.call('/posts/new', params)
and in tests this syntax is used
result = api.call('/posts/new', params)
when a developer wants to understand the interface of a dao application
she does this
vi app/api.rb
when a developer of a dao application wants to play with a dao application
interactively she does
(rails console)
> api = Api.new result = api.call('/posts/new', params)
when a remote client wants to understand the api of a dao application she
does
curl --silent http://dao.app.com/api | less
this kind of brutally consistent interface is made possible by structuring
access to data around the finest data structure of all time - the hash.
in the case of dao the hash is a well structured and slightly clever hash,
but a simple hash interface is the basis of every bit of goodness dao has
to offer.
in dao, application developers do not bring models into controllers and,
especially not into views. instead, a unified interface to application
logic and data is used everywhere: in tests, in controllers, from the
command-line, and also from javascript.
this seperation of concerns brings with it many, many desirable qualities:
- total seperation of concerns between the front and back end of a web
application. when developers are using dao changes to the data model
have zero effect on controllers and views.
- issues related to having models in controllers and views such as
difficulty reasoning about caching and n+1 queries in views killing
the db simply disappear.
- bad programming practices like using quasi-global variables
(current_user) or decorating models with view specific attributes
(password_verification) are no longer needed.
- developers are able to reason over the abilities of an application by
reading only a few source files.
- databases can be swapped, mixed, or alternate storage/caching
mechanisms added at any time without affecting the application's
controllers or views.
- transition from form based views to semi-ajax ones to fully-ajax ones
is direct.
- forms and interfaces that involve dozens of models are as easy to deal
with as simple ones.
- code can be optimized at the interface
READING
http://blog.plataformatec.com.br/2012/03/barebone-models-to-use-with-actionpack-in-rails-4-0/
http://martinfowler.com/eaaCatalog/serviceLayer.html
http://blog.firsthand.ca/2011/10/rails-is-not-your-application.html
http://best-practice-software-engineering.ifs.tuwien.ac.at/patterns/dao.html
http://www.codefutures.com/data-access-object/
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
http://www.paperplanes.de/2010/5/7/activerecord_callbacks_ruined_my_life.html
http://google-styleguide.googlecode.com/svn/trunk/jsoncstyleguide.xml
http://pragdave.blogs.pragprog.com/pragdave/2007/03/the_radar_archi.html
http://borisstaal.com/post/22586260753/mvc-in-a-browser-vs-reality
INSTALL
gem 'dao', :path => File.expand_path('..') ### Gemfile
rails generate dao api
vim -o app/api.rb app/controllers/api_controller.rb
curl --silent http://0.0.0.0:3000/api
curl --silent http://0.0.0.0:3000/api/ping
HISTORY
4.0.0
- dao depends has tied itself to rails, for better or worse...
- drop custom form encoding. just use a rack-like approach.
- dao form parameter encoding has changed slightly to 'dao[/api/path][x,y,z]=42'
- dao form paramters are now preparsed in a before filter