A question of when to instantiate

[thechaosengine]

Hi everyone,

I've been looking at the various ways to create a data access layer recently.
There was one thing in particular that occured to me and I was hoping to
garner some experienced insight into the matter.

Some people create a DA component that requires instantiation before use.
For example:

DataAccessComponent dac = new DataAccessComponent(connectionString);
DataSet results = dac.GetLoggedInUsers();

Other people, myself included don't seem to see the point in actually going
to the trouble of instantiating an object to do this. We would actually just
use static methods:

DataSet results = DataAccessComponent.GetLoggedInUsers();

At first look, the instantiation of an object to do this sort of stuff doesnt
seem at all neccessary - static methods work perfectly fine.

So I'm wondering if I have over looked some aspect of this problem.

Can anyone imagine a (common) situation in which instantiation has definite
benefits over the use of static classes?

Thanks to anyone who can offer any advice

Kindest Regards

TCE

[jabailo]

thechaosengine wrote:

So I'm wondering if I have over looked some aspect of this problem.
Can anyone imagine a (common) situation in which instantiation has
definite benefits over the use of static classes?

What if you want to use it twice, simultaneously, for two different
purposes, with different parameter inputs to the constructor?

If you're just building global methods that never change, then sure, it
doesn't matter...you might as well make it static, but a truly useful
"layer" should have some sort of configurability...

[thechaosengine]

Hi jabailo

Thanks for your reply!

I'm not quite sure what you mean though. Surely the sort of configurability
that you wish to achieve can be had by using overloaded static methods and
by passing well considered parameters - just as you would with an instantiated
object?

Where do you see the difference occuring?

Many thanks

tce

[jabailo]

thechaosengine wrote:

Hi jabailo

Thanks for your reply!

I'm not quite sure what you mean though. Surely the sort of
configurability that you wish to achieve can be had by using overloaded
static methods and by passing well considered parameters - just as you
would with an instantiated object?

Where do you see the difference occuring?

Many thanks

tce

A static object would retain the parameters. It's 'static' in memory.

So, say you want to have two objects. One connected to tableA and the
other to tableB.

With a static, you would set it to A, and then overwrite that setting to B.

So it's always A or B, but not both.

With an instantiated object, you could create two independent data
objects, one set to A and the other to B.

You can then use the object that is instantiated with A, and also, the
object that is instantiated with B.
It really depends on your design. For example, if your data access
layer, has a relatively fixed set of data tables and tasks, then you
might want to go static, because you want to have some nice methods for
easily inserting records to a table.

But say you want the ability to have open several data objects, all of
which have similarities, but also have slight differences. And these
differences might be by data. So you would have a common set of
methods that do inserts, but you would have one object for full time
employees, and another for temp employees. You might even want to have
a common data object which is inherited by child classes overriding the
base insert methods.

But the key thing is what is your requirement, and your design preference.

[Bob Milton]

And what if I need to access two different data sources at the same
time? If I go to copy a few million records between two databases on
different servers, the time penalty for opening a new connection for each
and every row can be staggering. Much better to open one connection to each
database and then copy.
Bob
"thechaosengine" <na> wrote in message
news:27*********************@news.microsoft.com...

Hi jabailo

Thanks for your reply!

I'm not quite sure what you mean though. Surely the sort of
configurability that you wish to achieve can be had by using overloaded
static methods and by passing well considered parameters - just as you
would with an instantiated object?

Where do you see the difference occuring?

Many thanks

tce

[thechaosengine]

Thanks for your insight. My requirements have thus far been rather modest.
My data layer doesnt normally require anything more fancy than some simple
CRUD type functionality with only a single datasource.

I can certainly see now where instantiation might have its uses. I'd just
noticed that some people seem to choose a position out of habit so I was
wondering what the real issues around the subject might be

Thanks again for your thoughts

tce