VB COM/OO/ADO design query

[mgergZ]

I have a query regarding a business object I am designing. Its the simple
scenario whereby I have a database holding products - a simple table - nothing
special here.
I want to create a component used by client apps to add or modify to this
table. The question is, what is the best design to encapsulate these objects
- ie, should one class be the database handling stuff, and another be the
product info. Or should i also include a collection class to handle them
all.
If having 2 or maybe 3 classes, would you make only one of them creatable,
the others being handled by it.
Further, the database is Oracle and requires username/password. The question
with this is; if i handle the database connection through one class, then
i cannot have the classes initialisation event establish the connection,
because i need to pass it this username/password, therefore do I have to
have it so that i have another method, say an "initDBconnection" method which
the client application must call before doing anything...

I hope that all makes sense, it is more a design question, so ideas as to
the best design would be much appreciated...I am new to COM & OO programming
so any help is needed.

[Richard Dalton .]

Hi,

"mgergZ" <mgergs@mbox.com.au> wrote:
>The question is, what is the best design to encapsulate these >objects ie,

that is indeed a good question.
You didn't mention how many clients apps would need to use
this component at the same time. People have different views
about what kind of load justifies using COM. Some people
suggest designing for it, and worrying about the load later.
I'd say if you know you'll have less than 20 users at a time
you should consider not using COM, but I know people
will disagree with me on that.

Now I'll try to answer your question in a way that can be
adapted for either COM or non COM.

>should one class be the database handling stuff, and another be >the product
info.

I think it's a good idea to have a class which can look after connection
to the DB, and can accept SQL or stored procedure names and can act on the
DB and if necessary return a recordset.

>Or should i also include a collection class to handle them all.

Not sure what you mean by collection, but I would suggest
building a ProductCollection class, which can load and manage
a number of Product objects. You're Product and ProductCollection classes
would then use your DB class to talk to the DB.

>If having 2 or maybe 3 classes, would you make only one of them >creatable,
the others being handled by it.

[I'm going to get a bit language specific here]
Depends on whether you want programmers to be able to create and manipulate
products in their own right. One approach that you'll
see a lot of is to have a bas object like your product collection
with a method called

CreateProduct(ar1, arg2, arg3, ...etc) as CProduct

the product class is then set to 'Public not creatable'.
this means that the only way to create a product is through the
use of the Product Collection.

Why would you want this?

Well, As far as I can see, there's only one reason.
VB doesn't do constructors (yet). So you can't initialise an
object while creating it. Using this technique you simulate
the concept of a constructor.

>Further, the database is Oracle and requires username/password. >The question
with this is; if i handle the database connection >through one class, then
i cannot have the classes >initialisation event establish the connection,
because i need >to pass it this username/password,

There are two approaches to this. One is to put a valid username
and password into the connection string and manage that string
with the DB object. This means that all client apps effectively
connect to the database as the same user. This allows you to
take advantage of connection pooling. You don't have to pass
anything from the client because the DB object knows how to
connect.

If you need users to conect to Oracle with different
usernames/passwords then this won't work, and you will have
to pass the info from the client. But have a look at ADO
connection strings and make sure that one all purpose user
won't do the job.

Now as for how to manage the connection string that's another
question. I've heard everything from, Ini-Files to The Registry
to "Hard Coding" it into the DB object.

Let's forget about hard coding it.

Apart from the fact that I just don't like the Registry I don't
know if there's a good idea not to use it. Ted Pattison
(MTS/COM+ Guy) suggested it was a bad idea at VBITS London for
performance reasons.

Presumably if the registry has performance issues then INI Files
do as well. I don't know how these compare.

If you are using COM+ the best option seems to be the constructor
string. I just said that VB doesn't do constructors. But in
COM+ there is a method of your object which can be called during
startup which accepts a string parameter. This string can be
specified in the COM+ admin tool. So you can stick your ADO
connection string, including UID and Password in there.

At the moment I use a combination of COM+ constructor and
INI files. If the object is built to run in COM+ it uses
the constructor, otherwise it's uses an INI file.

Hope this makes sense.
I also hope I haven't written a lot of bull, but that's
a distinct possibility. My mind is on the Christmas Shopping
that I haven't done yet.

-Richard

[Bob Butler]

<Richard Dalton .> wrote in message news:3a43632c$1@news.devx.com...
<cut>
> Why would you want this?
>
> Well, As far as I can see, there's only one reason.
> VB doesn't do constructors (yet). So you can't initialise an
> object while creating it. Using this technique you simulate
> the concept of a constructor.

Another reason may depend on the design of the objects. Using this example,
I've often done minimal Product classes that have no save/load/etc and kept
all that in the ProductCollection class. In that case the collection class
absolutely needs to know about any items that exist and the two choices are
to allow the client to create items on the fly and then Add them to the
collection or to force the client to create them only through the
collection. I find that using the latter approach simplifies the coding
both for the collection and for the client.

[mgergZ]

Hi Richard,

interesting reply - thanks,
My question now though, is, how is any of this "..either COM or non COM."

I mean, isn't the whole idea of COM using component objects - so isn't all
that you have discussed COM-related??

Most probably my understanding of COM/Objects/Classes is not too clear so
can you clarify this for me.

thanks a lot


"Richard Dalton" . wrote:
>
>Hi,
>
>"mgergZ" <mgergs@mbox.com.au> wrote:
>>The question is, what is the best design to encapsulate these >objects
ie,
>
>that is indeed a good question.
>You didn't mention how many clients apps would need to use
>this component at the same time. People have different views
>about what kind of load justifies using COM. Some people
>suggest designing for it, and worrying about the load later.
>I'd say if you know you'll have less than 20 users at a time
>you should consider not using COM, but I know people
>will disagree with me on that.
>
>Now I'll try to answer your question in a way that can be
>adapted for either COM or non COM.
>
>>should one class be the database handling stuff, and another be >the product
>info.
>
>I think it's a good idea to have a class which can look after connection
>to the DB, and can accept SQL or stored procedure names and can act on the
>DB and if necessary return a recordset.
>
>>Or should i also include a collection class to handle them all.
>
>Not sure what you mean by collection, but I would suggest
>building a ProductCollection class, which can load and manage
>a number of Product objects. You're Product and ProductCollection classes
>would then use your DB class to talk to the DB.
>
>>If having 2 or maybe 3 classes, would you make only one of them >creatable,
>the others being handled by it.
>
>[I'm going to get a bit language specific here]
>Depends on whether you want programmers to be able to create and manipulate
>products in their own right. One approach that you'll
>see a lot of is to have a bas object like your product collection
>with a method called
>
> CreateProduct(ar1, arg2, arg3, ...etc) as CProduct
>
>the product class is then set to 'Public not creatable'.
>this means that the only way to create a product is through the
>use of the Product Collection.
>
>Why would you want this?
>
>Well, As far as I can see, there's only one reason.
>VB doesn't do constructors (yet). So you can't initialise an
>object while creating it. Using this technique you simulate
>the concept of a constructor.
>
>>Further, the database is Oracle and requires username/password. >The question
>with this is; if i handle the database connection >through one class, then
>i cannot have the classes >initialisation event establish the connection,
>because i need >to pass it this username/password,
>
>There are two approaches to this. One is to put a valid username
>and password into the connection string and manage that string
>with the DB object. This means that all client apps effectively
>connect to the database as the same user. This allows you to
>take advantage of connection pooling. You don't have to pass
>anything from the client because the DB object knows how to
>connect.
>
>If you need users to conect to Oracle with different
>usernames/passwords then this won't work, and you will have
>to pass the info from the client. But have a look at ADO
>connection strings and make sure that one all purpose user
>won't do the job.
>
>Now as for how to manage the connection string that's another
>question. I've heard everything from, Ini-Files to The Registry
>to "Hard Coding" it into the DB object.
>
>Let's forget about hard coding it.
>
>Apart from the fact that I just don't like the Registry I don't
>know if there's a good idea not to use it. Ted Pattison
>(MTS/COM+ Guy) suggested it was a bad idea at VBITS London for
>performance reasons.
>
>Presumably if the registry has performance issues then INI Files
>do as well. I don't know how these compare.
>
>If you are using COM+ the best option seems to be the constructor
>string. I just said that VB doesn't do constructors. But in
>COM+ there is a method of your object which can be called during
>startup which accepts a string parameter. This string can be
>specified in the COM+ admin tool. So you can stick your ADO
>connection string, including UID and Password in there.
>
>At the moment I use a combination of COM+ constructor and
>INI files. If the object is built to run in COM+ it uses
>the constructor, otherwise it's uses an INI file.
>
>Hope this makes sense.
>I also hope I haven't written a lot of bull, but that's
>a distinct possibility. My mind is on the Christmas Shopping
>that I haven't done yet.
>
>-Richard

[Richard Dalton .]

"mgergZ" <mgergs@mbox.com.au> wrote:

>interesting reply - thanks,
>My question now though, is, how is any of this "..either COM or >non COM."
>
>I mean, isn't the whole idea of COM using component objects - >so isn't
all that you have discussed COM-related??

Ah! What is COM? Now that's a much more difficult question to
answer. I think I read a post recently that describes all
of the things that are COM. Have a search.

But, to answer your question. You may or may not already
know what I'm going to say, so apologies in advance if I'm
answering the wrong question.

COM is a protocol, it describes how components talk to each
other. As long as you're a COM component you can talk to other
COM components. It's like a Tux at a posh party.

When you make ActiveX dlls or ActiveX exe's in VB they are
automatically conferred with the honour of being COM components.
(They are dressed up in a suitable Tux, and are on the guest
list for all the best parties).

But there is another side to COM. It is also a piece of software, a tool.
it used to be Called Microsoft Transaction Server (MTS) now called COM+.
This tool manages the creation execution and destruction of objects. It
also manages transactions involving those objects.

Now, you can take an ActiveX DLL or EXE and run it outside
of MTS/COM+ and it will work just fine. It's still a COM
component, but it's just not running in the MTS/COM+ environment.
This means that any code you have in the EXE or DLL to interact
with MTS/COM is useless, but the rest of it should work fine.

This is what I meant when I said that you can't use the
Constructor String when running outside of COM. You have to
use an INI File. The constructor string is a feature of COM+.

Incidently the constructor string wasn't in MTS, so even if you
are running in MTS you'll have to use an alternative like INI
files.

I hope this clears up what I mean when I talk about running in
and out of COM. Yes it's all COM in the sense that all VB
components are COM components, but once developed they
don't have to be managed within the COM environment (MTS/COM+).

Now the question of why you would use MTS/COM+, is another
story.

Hope this helps.

-Richard

[Matthew Cromer]

>At the moment I use a combination of COM+ constructor and
>INI files. If the object is built to run in COM+ it uses
>the constructor, otherwise it's uses an INI file.

We are using Oracle and right now our VB stuff does have one SID and connection
info hardcoded. It really should go into an XML file IMHO.

Our java stuff does use an XML file to store this single DB connection (called
the bootstrap connection).

The bootstrap info connects to the bootstrap DB where all the other connection
info is stored for additional "products" (in our nomenclature).

Heck, it gave me an excuse to mess with XML. ;-)

Matthew Cromer

[Vain Freeman]

"mgergZ" <mgergs@mbox.com.au> wrote:
>
>I have a query regarding a business object I am designing. Its the simple
>scenario whereby I have a database holding products - a simple table - nothing
>special here.
>I want to create a component used by client apps to add or modify to this
>table. The question is, what is the best design to encapsulate these objects
>- ie, should one class be the database handling stuff, and another be the
>product info. Or should i also include a collection class to handle them
>all.
>If having 2 or maybe 3 classes, would you make only one of them creatable,
>the others being handled by it.
>Further, the database is Oracle and requires username/password. The question
>with this is; if i handle the database connection through one class, then
>i cannot have the classes initialisation event establish the connection,
>because i need to pass it this username/password, therefore do I have to
>have it so that i have another method, say an "initDBconnection" method
which
>the client application must call before doing anything...
>
>I hope that all makes sense, it is more a design question, so ideas as to
>the best design would be much appreciated...I am new to COM & OO programming
>so any help is needed.
>
(From Vain Freeman)
For the dataaccess and connection to the database I normaly use a separate
COM component with two classes.

The one class "comDataAccess" is a Multi-use class that instantiates an instance
of the second class which is public not creatable "clsDataService".

The method in the primary class "comDataAccess" is as follows...

Public Function GetDataComponent(byval user as string, byval pwd as string)
as clsDataAccess

dim tmpDataAccess as clsDataAccess

on error goto GetDataCommErr

set tmpDataAccess = new clsDataService

with tmpDataAccess
.UserId = trim(user)
.Password = trim(pwd)
end with

set GetDataComponent = tmpDataAccess

exit function

GetDataComErr:
err.raise err.number
end function

The above object will create and pass the dataaccess object to the calling
business object. The dataAccess object contains a simple ExecuteSQL method
that is invoked by the business object with the desired sql statement. This
method in turn calls a private connect procedure using the UserId and Password
properties for the connect string.

Once the connection is made it then opens an ADO connection to populate the
recordset object, calls another private function to disconnect from the database
and passes the disconnected recordset to the calling business object.