"Edwinah63" wrote...
[snipped legacy code]
Hi Bjorn,
many thanks for your reply. and yes, i think callable statements are
probably more appropriate.
>>Why would you want to ignore the connection?
well, i don't. i just want to create a callable/prepared statement
that is not associated with a specific connection; this means an object
only needs to know about itself and nothing about the database.
i want all my objects to be completely discreet.
for brevity i'm going to leave out much of the code i would normally
put in so you get the gist:
eg
cPerson
(
public Hair_colour as string
public Height as int
public function Createcommand() as adodb.command
dim cmd as ADODB.Command
cmd = New ADODB.Command
With cmd
.CommandType = adCmdStoredProc
.CommandText = "UpdateEmp"
.Parameters.Append( .CreateParameter(, adLongVarChar,
adParamInput, Len(hair_colour), Hair_colour) )
.Parameters.Append( .CreateParameter(, adInteger,
adParamInput,, Height) )
end with
'return the object
set CreateCommand = cmd
end function
)
function SomeOtherFunction
dim emp as cPerson
set emp = new cPerson
//get values from user
emp.hair_colour = "blonde"
emp.height = 180
//save it to the database
DatabaseManagerObject.Save(emp.createCommand())
DatabaseManagerObject
(
private function Conn() as adodb.connection //code to create the
connection
public function Save(cmd as adodb.command) //save using a command
object
cmd.activeconnection = Conn
cmd.execute
//here is all the error handling to for this kind of transaction
etc
end function
public Save(sql as string) //save via a literal sql string
)
as you can see from the above, i can minimise redundant code, and each
object only needs to do enough to manage itself, nothing more.
>>though I believe it's not the best way to go about things...
i am open to suggestions here, the VB way is not necessarily the Java
way. now you know what i am trying to achieve, what would be a better
design??
regards
Edwinah63
Edwinah63 - 23 Nov 2005 04:55 GMT
BTW, another version of the DatabaseManagerObject.Save() function could
be:
public function Save(cmd as adodb.command) //save using a command
object
Conn.begintrans
cmd.activeconnection = Conn
cmd.execute
if err.count = 0 then Conn.commit else Conn.rollback
//plus all the error handling to for this kind of transaction etc
end function
you get the idea.
Bjorn Abelli - 23 Nov 2005 10:47 GMT
"Edwinah63" wrote...
> i want all my objects to be completely discreet.
So why make them "DB-aware" at all... ;-)
[snipped code]
> i am open to suggestions here, the VB way is not
> necessarily the Java way. now you know what i am
> trying to achieve, what would be a better design??
Well, there are a lot of options here, as well as opinions on what the best
design really should be, but I'll try to at least give you some quick
pointers. At least they will do about the same thing as you want to, even
though there might be even better designs if you would look at the "whole
picture"...
Anyway, here goes...
import java.sql.*;
// I prefer to separate the Person
// from how to "save" her...
class Person
{
// I would use setters and getters instead
// here, but for this example I skip it...
public String hairColour;
public int height;
}
// In OOP we use interfaces a lot... ;-)
interface DbObject
{
void save(Connection conn);
}
// ...so we use that to encapsulate a "real" object
// and make the rest more polymorphic...
class DbPerson implements DbObject
{
private Person p = null;
public DbPerson(Person p)
{
this.p = p;
}
public void save(Connection myConnection)
{
CallableStatement cs = null;
try
{
cs =
myConnection.prepareCall
("{call UpdateEmp(?, ?)}");
cs.setString(1, p.hairColour);
cs.setInt(2, p.height);
cs.execute();
cs.close();
}
catch (SQLException sx)
{
// Perform error handling here...
}
}
}
// I'm not sure how DatabaseManagerObject fits
// into the rest, as this also can depend on other
// considerations, db-wise and others...
class DatabaseManagerObject
{
private Connection getConnection()
{
Connection conn = null;
// ToDo: Create a Connection...
// ...or if there's another one
// as an instance field somewhere...
return conn;
}
// As you see, we only need to know that
// the object has a method to "save", not
// what it saves, or how...
public void save(DbObject dbo)
{
try
{
Connection conn = getConnection();
// Now we only have to let the object
// "save itself"...
dbo.save(conn);
// Whether or not you'll close conn here,
// is rather depending on how the
// DatabaseManagerObject itself will be
// constructed, but as this only
// is an example, we go for that now...
conn.close();
}
catch (SQLException sx)
{
// Perform error handling...
}
}
public void save(String sql)
{
// Implement an "ordinary" statement
// handling here...
}
}
class WhatEver
{
public void someOtherFunction()
{
// To actually know how to construct
// the DatabaseManagerObject, there
// are more things to consider,
// db-wise and others...
DatabaseManagerObject dbmo =
new DatabaseManagerObject();
// ...and possibly the Persons already
// exist in a list of some sort, but
// I follow what you did here...
Person emp = new Person();
// get values from user...
emp.hairColour = "blonde";
emp.height = 180;
// save it to the database
dbmo.save(new DbPerson(emp));
}
}
I hope this helps...
// Bjorn A
Edwinah63 - 30 Nov 2005 00:12 GMT
it most certainly does!!!
the DatabaseManagerObject knows about the database and how to interact
with it, depending on whether it is given a command object or a string
(in this example), but nothing about the object to be saved.
the object to be saved knows about how to generate the command object
or the sql string literal it needs to save itself, but nothing about
the database. this way, i can minimise my code big time.
thank you for taking the time to create the example for me. vb is not
a true OOP language (tho' vb.net is).
i will take what you have written into my design consideration.
if you know of any good Java object design web pages, please let me
know.
:-)