Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re: Re: Object DBI concepts

by Angel (Friar)
on Nov 08, 2002 at 01:59 UTC ( [id://211310]=note: print w/replies, xml ) Need Help??


in reply to Re: Object DBI concepts
in thread Object DBI concepts

1. Yes that is the reason for attempting this so that each programmer ( they are volunteers ) can just use this object and have the user data at their fingertips and only have to worry about their departments specific data.

2. Yes it will I was figuring just having the complete DB code inside that object so that if I need to I can edit that bit only and then everyone elses code will still continue to work. I dont understand how keeping the DB access code seperate helps? And how do I pass the db handle as a reference? You would set that upon instantation of the object right?

The users are interacting via CGI and they can update their data through the cgi inteface. I was figuring a tool for the programmers to use this way we all use the same validation methods on the core user data.

Replies are listed 'Best First'.
Re: Re: Re: Object DBI concepts
by djantzen (Priest) on Nov 08, 2002 at 02:31 UTC

    Okay, so some other programmer will be writing, say, a command line script that requires connection to your DB, and you want them simply to create an object to give them access to your data. I was thinking mostly in terms of requests coming in through a web server.

    One option then is to write a module with a constructor capable of creating the connection, which is in turn instantiated as part of the instantiation of your user data access module. Here's a rough and ready sketch:

    package UserDBConn; sub new { my ($class, $param1, $param2 ...) = @_; my $this = bless({}, $class); # store the returned DB handle in a private slot $this->{_db} = DBI->connect($param1, $param2 ...); } sub getDBHandle { return $_[0]->{_db}; } package User; # lexically scoped at file level so you can create multiple # instances of this module within this process using the # same UserDBConn. Creating a new DB connection each time # you want to pull out a user's information would be *bad*. my $user_db_conn; # = new UserDBConn(...); sub new { my ($class, $username, $more_stuff) = @_; my $this = bless({}, $class); $user_db_conn ||= new UserDBConn(...); # now use $user_db_con->getDBHandle() to populate $this } sub setX {} sub getX {} sub save { # write all our data to the table }

    This approach has the benefit of creating a reusable custom wrapper module around your DBI connection, meaning you can utilize it in other circumstances. Plus you've got the separation of business logic dealing with your user data from the database connection logic. And, your fellow programmers in other departments have no need to know anything about the DB connection under the covers.

      Ok I am starting to understand what about calling it? You gave me all of these modules and what I am really trying to do is give a tool kit ot myself and my people so that when I need to edit the way sessions are stored and users are handled it does not break as this eventually is going to have alot of people working on it.

      At the beginning of my script I open a connection to the database and just use it. I have done that it works well. Now I want to provide a set of functions for my self and my people to access that database but not from cutting and pasting the files into each script as they are written.

      I guess I need more of a module then? And have when needed thm call in the function as in user::validate_username ?

        ...what about calling it? You gave me all of these modules and what I am really trying to do is give a tool kit ot myself and my people...

        What we're talking about developing is an Application Programming Interface -- a standardized manner of accessing particular data and effecting actions upon it. I described a model in which you could use (a mere) two modules, one of which to be used by your fellow programmers directly (the 'User' module), and the other that only you need to be concerned with directly ('UserDBConn').

        Now I want to provide a set of functions ... to access that database but not from cutting and pasting the files into each script as they are written.

        And modules are clearly a good way to do this. If you need to modify behavior in some way, say with openning the DB connection, you simply change the code in UserDBConn and release that mod to your fellow developers. Their code doesn't have to change a bit.

        HTH, fever

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://211310]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others admiring the Monastery: (7)
As of 2024-04-19 14:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found