Global Functions

  • Thread starter Thread starter Anil Gupte
  • Start date Start date
A

Anil Gupte

I am trying to set up a function that connects to the database that I can
then use gloablly. I set up a class called L3Global in which I have a
function as follows:

Public Function SetDBConnect()
Dim ConnStrL3Producer As String
ConnStrL3Producer = "User ID=UID;Tag with column collation when
possible=False;Data Source=" & Chr(34) & "a.b.c.d" & Chr(34) &
";Password=PWD;"
ConnStrL3Producer = ConnStrL3Producer & "Initial Catalog=L3;Use Procedure
for Prepare=1;Auto Translate=True;Persist Security Info=True;Provider="
ConnStrL3Producer = ConnStrL3Producer & Chr(34) & "SQLOLEDB.1" & Chr(34) &
";Workstation ID=AUM;Use Encryption for Data=False;Packet Size=4096"
Dim ConnL3Producer As New OleDbConnection(ConnStrL3Producer)
Return ConnL3Producer
End Function

Now I want to use this is all my forms (MDI). I set up
Public L3G As New L3Global

and then under the approporate button click I have:
Dim ConnL3Producer As New OleDbConnection

ConnL3Producer = L3G.SetDBConnect

The problem is, do I have to setup an instance of L3Global in each form?
That defeats the purpose, because each one opens a new connection. How can
I use this connection object in all my forms but open it only once? Ideally
I would like to move as much of the intialization (creating the OLEDBAdapter
etc) to the global routine.

Thanx for any suggestions.
 
Well i would not recomend a global connection aproach in .Net

Because of the superb connection pool mechanism , you can now safely and
without anny performance overhead create , use , and destroy
especially the using statement is verry handy with this

personally i would store the connection string in the config file

regards

Michel
 
Thanx for that tip, but please explain:
"...especially the using statement is verry handy with this"

and also
"...personally i would store the connection string in the config file"

I am a newbie at .Net and last used VB five years ago for a few months.
 
Hmm, I must be in a parallel universe. Just kidding of course, but I did
not follow most of what I read on those links, and I am not that much of a
programmer (nor do I ever hope to be). I am just building a prototype of
software that I want real programmers to write.

Anyway, if you have seen specific tutorials relating to this, please do let
me know.

Anyway Thanx,
 
A fairly common problem developers run into is having non-developers explain
how to develop applications :-) I'll suggest that you ordinarily wouldn't
need to explain to a developer your preference for a single connection,
globally accessible from anywhere in the application. The developer(s) can
figure out a) if that is a good idea and b) how best to implement it.

Design patterns have been around for a very long time but (more or less)
recently were given names and categorized. There are many books and
thousands of articles on the subject but in a nutshell most of what
developers do isn't "new" and whether we are instantiating a customer,
inventory item, baseball score or anything else the process is the same. I
don't mean that the code exists I mean the "pattern" that the code will
follow exists. Your house may look completely different from another but it
will have a foundation, walls and a roof, those are givens.

Bottom line is when you have some time consider reading an introduction
articles on design patterns. If it does nothing else you may have the "aha"
moment when you find something you've been trying to explain to a developer
actually has a name and everybody already knows about it.

Also if you create a singleton class your "I don't want two instances"
problem goes away. There may be a dozen other tricky ways to do it but ask
yourself what is the advantage to not using a proven design that everybody
else is using?

Take care,
Tom
 
Anil said:
I am trying to set up a function that connects to the database that I can
then use gloablly. I set up a class called L3Global in which I have a
function as follows:
Click to expand...
Public Function SetDBConnect()
Click to expand...
Now I want to use this is all my forms (MDI). I set up
Public L3G As New L3Global

and then under the approporate button click I have:
Dim ConnL3Producer As New OleDbConnection

ConnL3Producer = L3G.SetDBConnect

The problem is, do I have to setup an instance of L3Global in each form?
That defeats the purpose, because each one opens a new connection. How can
I use this connection object in all my forms but open it only once? Ideally
I would like to move as much of the intialization (creating the OLEDBAdapter
etc) to the global routine.
Click to expand...
<snip>

I guess you can declare a Module, instead of a class:

<aircode>
Module L3Global
Private mConnection As OleDBConnection

Public Function ConnectDB() As OleDBConnection
If mConnection Is Nothing Then
Dim ConText As String = "Your connection string"
mCOnnection = New OleDBConnectins(ConText)
End If
Return mConnection
End Function
End Module
</aircode>

And then, in your Forms you'd have:

Dim ConnL3Producer _
As OleDbConnection = L3Global.ConnectDB()

Improvise over that.

Regards,

Branco.
 
Because you are not that much of a programmer (nor do you ever hope to be),
I strongly suggest that you do NOT build a prototype of software that you
want real programmers to write.

Instead, write a specification document that describes, at a fairly high
level, the purpose of the software, what the 'inputs' are, what the
'outputs' must be and what the expected outcomes are. Include details of
business rules and pictures of what various forms and reports should look
like. If there are any aspects of the specification that are immutable then
make those aspect clear and unambiguous. Also include details of what
technologies may or may not be used.

You will find that a real programmer, when presented with such a document,
will have no problems figuring out the best way to implement the design and
will be more productive than having to work from a protoype developed by
someone who doesn't really know what they are doing.
 
Thanx, that will get me started. Do you happen to know any place where I
can read more about when to use a Module and when to use a class?

Thanx again,
 
Anil: Yes you can read it right here :-) Never use a module!

VB.Net is an object-oriented language and by definition that should lead to
object-oriented solutions. If there is no OOP solution (and that would seem
unlikely given apps written in SmallTalk, C++, Java, C# and all the other
OOP-based languages) then one might find themselves forced into having to
resort to a "hack". Take my word for it don't start with the "hack" or you
will never stop applying hacks. People will stare at your code and giggle
behind your back...

What you are describing isn't a "module" you are describing a Singleton
Class. If you want to read something perhaps about the Singleton Class
would be a good start.

Try it you may like it.
 
Tom,

I hope to disappoint you, however it seems that C# programmers cannot stand
the word "module".

However a singleton C# class is as far as I know nothing more than a module,
which residence at the stack.

Beside the slight misbehaviour that a variable declared in a module can be
called in VB.Net without its module name, is in my idea the module much
nicer for declaring and using shared parts in a program.

I would never write, "Never use a module", I agree with you when it becomes.
"Try to avoid a module, static class, singleton, shared class or whatever
you name them."

Cor
 
Hi Cor (and Dennis):

A quick search of newsgroup messages reveals that similar conversations have
taken place before. One in particular involved Kevin Spencer explaining why
the VB Module exists (backwards compatibility) and offering his opinion that
it should have been removed. I agree with him.

While it may constitute "a class with static properties and no constructor"
I see no reason to provide a second syntax for creating such a thing. Why
not a third or fourth syntax as well? I really don't want to rehash all the
points because for every point made there will be a counterpoint and we
simply duplicate countless other threads.

I would hesitate to describe it as a Singleton class however. There is in
fact a single object in a Singleton class and all properties do not need to
be static. The instantiation of that object can be delayed until "first
use". One can obtain a reference to the singleton object which can be
passed as a parameter to other methods. If these things can be done with
the VB module that's cool but again I ask why do we need two ways to obtain
identical results? Furthermore we cannot create a singleton class using
Module syntax subclassed from an arbitrary class right? So it is not only a
"dupe" it is a limited use duplication.

I believe it comes down to clarity of design. I can't explain it better but
we don't need a language to implement every person's favorite way to do
something. If anybody wants "module" functionality couldn't they simply
declare a class in the way that the module does and get it? There it is,
available to anybody who wants it, not part of the official language syntax,
not misinterpreted as being a VB feature, etc.

Cor, you're misinterpreting or simply guessing. It isn't that C#
programmers can or cannot stand the word module. A C programmer doesn't
think more clearly than a VB programmer, a dBASE programmer doesn't rank
somewhere in a good programmer chart. There are good and bad (shall we call
them neat and sloppy) programmers using every language. There is often a
division between people who love having "&" and "+" available to concatenate
strings and those who ask, why two operators? Some may find two ways "a
brilliant design" while others will say it creates unnecessary ambiguity. I
wouldn't say that C# developers find it odd and VB developers find it cool.

The VB module doesn't add anything to the language (that I am aware of) and
as such it should be removed from the language.
 
Tom,

A class in OOP has to be instanced, (you wrote it in my idea yourself) so
that it can sit on the heap. You are true that I am guessing that a
Singleton Class is doing the same as a so called not official existing
Static Class in C# does, I could not yet find it where it residence, so I
should not have written that. There are differences in with the VB Module
and the Singleton, however as much as the behaviour between + and $
concationation in VB.

I like however the name "Module". It makes it for me very clear, that a
module is not a class, it is a part of the main object as it is fixed in the
program. An instances object however sits on the managed heap and will be as
as soon as that is possible removed. I find this name Module therefore nicer
than any Shared/Static class, which is in fact no class in the OOP meaning.

It is possible to write a Module in the same way as a class, and be than not
forced to use the Shared keyword. In a very short discussion between Kevin
Spencer and me about this (with a very small sample from me) he somewhere
wrote a relative short while ago something in these newsgroups as. "You are
right Cor, I did not know this behaviour from the Module". However, to
search special messages on Google from either Kevin or me is not easy.

Cor
 
Tom,

My expection that the Singleton is not instanced but seats on the Main part
is that it is in my eyes very inefficient to do it in another way if it has
to be forever in a program.

Cor
 
Tom Leylan wrote (inline):
Anil: Yes you can read it right here :-) Never use a module!
Click to expand...

I wouldn't go as far as to recommend to *never* use a module. There are
times when the extra syntax needed to create a module-like class just
gets in the way. VB gives you the tools and a Module is just one of
them. Understand it and use it.
VB.Net is an object-oriented language and by definition that should lead to
object-oriented solutions. If there is no OOP solution (and that would seem
unlikely given apps written in SmallTalk, C++, Java, C# and all the other
OOP-based languages) then one might find themselves forced into having to
resort to a "hack". Take my word for it don't start with the "hack" or you
will never stop applying hacks. People will stare at your code and giggle
behind your back...
Click to expand...

Yep, the C# 2.0 folks would do that, allright. They'd say "Look, they
call static classes a 'module'!". =)))

BTW, C++ folks may also be intrigued by why are we using such an arcane
construct, cause 99% of the C++ coders I know write OOP-only code...
oops, sorry, I guess I got these stats reversed.
What you are describing isn't a "module" you are describing a Singleton
Class. If you want to read something perhaps about the Singleton Class
would be a good start.
Click to expand...

No arguing about that... =)

One of the ways to provide singleton-like functionality is to hide the
actual singleton inside a, uh, module, and provide only controlled
access to it through the methods of the module. Of course, you may
approach singletons however you like. Unfortunately, IMHO, the
SomeClassWithPrivateConstructor.CreateInstance() approach to
singletons, besides tasting much like Java, lacks the clarity of the
good old "New Someclass()".

Regards,

Branco.
 
Hi Branco:

Branco Medeiros said:
Tom Leylan wrote (inline):


I wouldn't go as far as to recommend to *never* use a module. There are
times when the extra syntax needed to create a module-like class just
gets in the way. VB gives you the tools and a Module is just one of
them. Understand it and use it.
Click to expand...

I'm not arguing mind you but perhaps you could illustrate one of those
times. My point in most of these discussions (regardless of the language)
is to ask why then haven't other languages adopted this really cool thing?
More dramatically if dBASE has a CLEAR ALL command which removes all
variables from memory (and it was a "good" feature rather than a horrid one)
why wouldn't the developers using C, Pascal, VB and such be begging for it?
Yep, the C# 2.0 folks would do that, allright. They'd say "Look, they
call static classes a 'module'!". =)))
Click to expand...

This is the part I don't understand. I have static classes in VB and I have
no modules so what am I missing? Why not eliminate the keyword CLASS from
VB and just call them all MODULE? I think it depends upon one's goal and
increasing the differences between languages shouldn't be a goal. If a
keyword is available in C# and in VB I see no reason to change one of them
in an effort to make things harder. I wouldn't add curly braces to VB but I
can't see using new words to describe common concepts. All I'm saying is if
a module is a static class what is the difficulty in calling them a static
class?
One of the ways to provide singleton-like functionality is to hide the
actual singleton inside a, uh, module, and provide only controlled
access to it through the methods of the module. Of course, you may
approach singletons however you like. Unfortunately, IMHO, the
SomeClassWithPrivateConstructor.CreateInstance() approach to
singletons, besides tasting much like Java, lacks the clarity of the
good old "New Someclass()".
Click to expand...

You can hide it anywhere you like but I haven't used a single module and I'm
not finding things harder to use or taking longer to write. I don't see the
upside and I see lots of downside to modules. I also don't see anything
wrong (from a language standpoint) with Java. I routinely steal good ideas
from every language I've ever encountered. I also don't use every feature
in a language just because it is available. That VB could reference a
variable without previously declaring it was something it could do but I
have yet to find an example that illustrated why it was needed or should be
used.

I understand that VB supports placing functions in modules, I'm suggesting
(in the long run) it isn't wise to do so.

Most people's mileage is likely to differ :-)
 
Tom Leylan wrote:
I'm not arguing mind you but perhaps you could illustrate one of those
times.
Click to expand...

I guess this actual thread illustrates such a case.
My point in most of these discussions (regardless of the language)
is to ask why then haven't other languages adopted this really cool thing?
More dramatically if dBASE has a CLEAR ALL command which removes all
variables from memory (and it was a "good" feature rather than a horrid one)
why wouldn't the developers using C, Pascal, VB and such be begging for it?
Click to expand...

This is not the point. It seems that every important -- some of them
even cool -- models of computation was already done with by now; modern
language developers are mostly adapting features and stealing sugar.
But languages sometimes don't borrow from one-another even when
something is "cool". Mostly there's a philosophy issue behind the
scenes. Maybe the "stealing" exists, but it's so subtle you can't even
see it's there. How many things Basic (and even VB) stole from Fortran?
How much Java stole from VB? (look very close and you'll see a lot). As
for "clear all", I kinda recall MSX-Basic (from Microsoft breed) had
something like that to clear the garbage collector allocated space,
back in, what, the 80s? C'mon...

I admire people who can code in Perl, and I'm not one of them. Not that
I lack the expertise, mind you, I really believe I can be an
average-to-good programmer in most programming languages (something
laughed here inside myself, but don't listen to it). I don't code in
Perl because the language doesn't appeal to me. VB, on the other side,
is cool in me, and I'm glad Modules have survived the transition to OOP
without becoming a hack. I'd rather declare a Module -- something the
VB programmer will immediatly recognize for what it is -- than to come
up with solutions such as having a shared Singleton() method in a final
class with a private constructor... Not that I'm saying I won't use
that, only that I preffer not to. On the other side, a public
ConnectDB() method inside a module will immediatly make it clear to me
that it's the global scope speaking.

This is the part I don't understand. I have static classes in VB and I have
no modules so what am I missing? Why not eliminate the keyword CLASS from
VB and just call them all MODULE? I think it depends upon one's goal and
increasing the differences between languages shouldn't be a goal. If a
keyword is available in C# and in VB I see no reason to change one of them
in an effort to make things harder. I wouldn't add curly braces to VB but I
can't see using new words to describe common concepts. All I'm saying is if
a module is a static class what is the difficulty in calling them a static
class?
Click to expand...

You're talking about the C# folks, right? Why they didn't call a static
class simply a module, right? Because, AFAIK, the module "concept"
existed in VB long before the C# folks noticed it. Nevertheless, a
couple of most likely reasons to why "static classes" are called Module
in VB: a) because the term "static" in VB has a very specific meaning,
different from the ones it has in C#/C++/Java/C: in such languages,
"static" inside a function declaration means the same as in VB: that
the variable is, er, static (i.e. preserved between calls). Outside a
function declaration, it designate elements shared by all instances of
a class (quite a different meaning, I guess you'll aggree). In VB, by
its turn, a method can be Static, which means that all its internal
variables are static. If you want the C# meaning you must use the term
"Shared". b) because the term "Module" already existed to represent the
exact same thing as C#'s "static class".

To be honest, I'm kinda proud of those keywords that represent
concepts that VB pioneered -- or at least brought to the general
knowledge -- and that were taken hold by other languages, sometimes
having their names changed to cover the evidenc... er, I mean, to suit
the language better, such as For Each, Event (for event-driven
programming), Interface, Module, etc.

This doesn't mean I even *like* those keywords VB invented to represent
concepts already stablished in the programming field (MustInherit and
NotInheritable to name a few).

You can hide it anywhere you like but I haven't used a single module and I'm
not finding things harder to use or taking longer to write. I don't see the
upside and I see lots of downside to modules. I also don't see anything
wrong (from a language standpoint) with Java.
Click to expand...

Ahw, sure. I just don't sympathize with that guy Scott. Taking that,
Java is ok to me. My point was that there's already A-Way-To-Do-IT (tm)
in VB, I'll use Java's way only if there's no VB way (or if the Java
way is more close to my liking. I'm a bitch, I know).

Notice that Java recently was given Properties, Enums and ForEach, and
two of those were practically born with VB (well, ForEach was born with
Pearl, and Properties were created by TurboPascal, to be exact, but I
doubt they'd have any importance if it wasn't for VB... After all, VB's
ForEach gave headaches to more than one C++ developer when it came to
programming IDispatch interfaces. Now every language demands a foreach
construct, but they should name it "VBForEach", to be honest. Nope,
just kidding, strike that).

Most people's mileage is likely to differ :-)
Click to expand...

This, I fully aggree.

Regards,

Branco.
 
responses inline:

Branco Medeiros said:
Tom Leylan wrote:



I guess this actual thread illustrates such a case.
Click to expand...

I just have to say then that I don't get it. If this thread illustrates an
example where the module is superior then how is every other OOP language
without modules going to do this? And it would seem I couldn't solve the
problem since I'm not going to use a module. Don't you see this thread
doesn't illustrate a great example but rather just "an" example. Nothing
that can't be solved as elegantly using class syntax which already exists.
This is not the point. It seems that every important -- some of them
even cool -- models of computation was already done with by now; modern
language developers are mostly adapting features and stealing sugar.
But languages sometimes don't borrow from one-another even when
something is "cool". Mostly there's a philosophy issue behind the
scenes. Maybe the "stealing" exists, but it's so subtle you can't even
see it's there. How many things Basic (and even VB) stole from Fortran?
How much Java stole from VB? (look very close and you'll see a lot). As
for "clear all", I kinda recall MSX-Basic (from Microsoft breed) had
something like that to clear the garbage collector allocated space,
back in, what, the 80s? C'mon...
Click to expand...

I'm going to guess that fundamentally everything in BASIC came from FORTRAN
via ALGOL. I'd also hazard a guess that virtually nothing from Java was
borrowed from VB. VB wasn't an OOP language and only now rivals Java.
You're mixing up whatever MSX-Basic did with what dBASE languages "do." And
I don't mean in 1980 I mean last week. I sense a "defend VB" thing going on
though, it's a language (an electronic toolset) not a religion.
I admire people who can code in Perl, and I'm not one of them. Not that
I lack the expertise, mind you, I really believe I can be an
average-to-good programmer in most programming languages (something
laughed here inside myself, but don't listen to it). I don't code in
Perl because the language doesn't appeal to me. VB, on the other side,
is cool in me, and I'm glad Modules have survived the transition to OOP
without becoming a hack. I'd rather declare a Module -- something the
VB programmer will immediatly recognize for what it is -- than to come
up with solutions such as having a shared Singleton() method in a final
class with a private constructor... Not that I'm saying I won't use
that, only that I preffer not to. On the other side, a public
ConnectDB() method inside a module will immediatly make it clear to me
that it's the global scope speaking.
Click to expand...

That's great and I think we should leave it at that. I'm not a "VB
programmer" I never hope to be one, I have never aspired to be one. I'm a
software developer. Personally I would rather use the ConnectDB() method of
the SQLServer class opening the possibility of my using the ConnectDB()
method of the OracleServer class without modifying a module. Again I
realize to the extreme that VB programmers belong to a cult and to be fair
so do "Java programmers", "SmallTalk programmers" and others who identify
with a toolset. Maybe it's time to start a thread about the best O/S or the
best CPU, it may have been a few days.
You're talking about the C# folks, right? Why they didn't call a static
class simply a module, right? Because, AFAIK, the module "concept"
existed in VB long before the C# folks noticed it.
Click to expand...

Okay thanks... the thread has died.
 
Tom Leylan wrote (inline):
responses inline:

I just have to say then that I don't get it. If this thread illustrates an
example where the module is superior then how is every other OOP language
without modules going to do this? And it would seem I couldn't solve the
problem since I'm not going to use a module. Don't you see this thread
doesn't illustrate a great example but rather just "an" example. Nothing
that can't be solved as elegantly using class syntax which already exists.
Click to expand...

I never said that this thread illustrates the superiority of modules
over classes. Only that it illustrates, to me, a situation where the
syntax of a module-like class would get in the way, to the point of
making me prefer to use a module instead of the class solution itself.

Okay thanks... the thread has died.
Click to expand...

Af! Ok, then.

Regards,

Branco.
(gets out musing about language wars, urban religions, cold coffee and
parsing engines)
 
Back
Top