sa-weet data access object library for rails. top secret.
Ruby JavaScript
Pull request Compare This branch is 221 commits behind ahoward:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.



  a sa-weet-ass library for structuring rails applications using the 'data
  access object' design pattern.

  applications that are written on dao look like this in ruby

    result ='/posts/new', params)

  and like this in javascript

    result ='/posts/new', params)

  in command-line applications they look like this

    result ='/posts/new', params)

  and in tests this syntax is used

    result ='/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 =
    > result ='/posts/new', params)

  when a remote client wants to understand the api of a dao application she

    curl --silent | 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

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

    - transition from form based views to semi-ajax ones to fully-ajax ones is

    - forms and interfaces that involve dozens of models are as easy to deal
      with as simple ones.

    - code can be optimized at the interface

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



  gem 'dao', :path => File.expand_path('..') ### Gemfile
  rails generate dao api
  vim -o app/api.rb app/controllers/api_controller.rb
  curl --silent
  curl --silent

    - 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