byterock

I think it is about time I got down to brass tacks and get some code written for this project of mine or at least look at it.

Well they say a picture is worth a thousand words and this little diagram (from a production instance, I too off all the names to save the innocent, will give you an idea of where I have used DA and how I see other using it.

So it sits out in left field as a separate class set that is connecting to Oracle. My app's abstract classes then instantiate these classes to actual work on the DB that is called by the Controller and API classes of the Mojo App.

No I know what some will say;

Why not just use ORM or Fey or some other ORM and skip both of these layers?

Well if I did that I would have a very short blog post and I am not going to open up the old ORM debate as there will be no winner. Lets just say it was the right choice, in this case as only a very limited part of a huge DB was being used.

So what did my Data Accessor class look like?

 
package XXX::DA::Collaborators;

use strict;

use warnings;

use base qw(DBIx::DA::SQL);

sub new {

   my $self = shift;

   $self = $self->SUPER::new(@_);

   $self->init()

      if (!$self->initialized());

   return $self;        

}

sub init {

        

   my $self = shift;

   $self->add_table({name=>'collaborator'});

   $self->add_fields([ {name=>'user_id'},

                       {name=>'contact_id', is_identity=>1},

                       {name=>'contact_id', alias=>"id",},

... 

     $self->add_static_inner_join({to_table=>'contact',

                          on_field=>'contact_id',

                          to_field=>'id'});  

   return $self;

}

You get the basic picture, tell the DA basic things about what you want from the DB in this case a view of the Collaborator table joined to some other tables to get a View that I could use.

This DA was used in the XXX:Abstract::Collaborators class like this

 
sub  mine
  my $self = shift;
  my $da = XXX::DA::Collaborators->new();
    $da->add_dynamic_condition({field =>'user_id',
                                         operator =>'=',
                                            param =>$self->id()}); 

  return $da->retrieve();

   

}

Now in the Controller or API Mojo class the code would look like this

 
sub get_my collaborators {
    my $self = shift;
    my $new =  XXX::DA::Collaborators->new(id=>$self->param('id'));
    my $objects = $new->mine();

    my $ref = {

        page    => "",

        records => scalar( @{$objects} ),

        total   => scalar( @{$objects} ),

        rows    => $objects,

    };

    $self->render( json => $ref );

}

In this project I wasn't involved with the Mojo UI side of things, though I did create the stub-site, my job was to create the DA and Abstract classes make sure the abstract classes where properly document and then just send that off to my little offshore Mojo coding minions,

With just the document and the back end in place they had all they needed to fill in all the blanks of the stubbed in API, Controller and UI code. If I remember correctly I only had a few emails regarding some typos in the doc and one short conferace call to go over how things were to work. By the way this was the only time when I have ever seen a succesfull offshore outsource, allbeit it was a small project.

So that is the 25 cent tour of how have used it in the past. Even with the small example here I can see some things that I really want to change. For example I really hate the calls like 'add_static_inner_join' and the ' add_dynamic_condition' though descriptive they are clunky and way too long. More importantly I the way 'sub new' and 'sub init' work has to go away this is a basically a hack I had to introduce when using my Orignal.pm as a base. Oh well live an learn