Can i create Command,Connection objects once inside a class
constructor and use them again and again by changing their values and
destroy them instead of creating objects everytime in a class member
function.......

On Feb 20, 2:15 pm, "weird0" <amiredi...@gmail.com> wrote:
> Can i create Command,Connection objects once inside a class
> constructor and use them again and again by changing their values and
> destroy them instead of creating objects everytime in a class member
> function.......

Hi,

Sure, but that's going to make your code harder to read and maintain.
There would also be an increased risk of bugs making their way into a
release. Ask youself whether or not those objects logically represent
the state of the class.

Brian

Hi,

"weird0" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Can i create Command,Connection objects once inside a class
> constructor and use them again and again by changing their values and
> destroy them instead of creating objects everytime in a class member
> function.......
>

Yep, a constructor is just the place for that.


Now, I advice you again doing what you plan, just create a new instance of
a command.

In case of a connection you should ALWAYS close the connection ASAP, in my
code I open and close the connection in the same method.

Maybe it's a good idea to look in the archives by "data access layer" you
will find good comments about how to handle connections/commands objects/


--
Ignacio Machin
machin AT laceupsolutions com

Best practices coding takes avantage of the ADO.NET connection pool, which is
usually a lot better at handling connections than any code you or I could
write.
The pattern is as follows:
1) Use the same connection string
2) Open the connection immediately before you use it.
3) Close the connection (and call Dispose on the Command) immediately after
using it.

This allows your connection objects to return to the ADO.NET connection pool
automatically, and they can be resurrected quickly and efficiently whenever
you need them again.

Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net




"weird0" wrote:

> Can i create Command,Connection objects once inside a class
> constructor and use them again and again by changing their values and
> destroy them instead of creating objects everytime in a class member
> function.......
>
>

And constructors are not a good place for that type of code. Constructors
should be used to create the object and as little other work as is possible.

Dale
--
Dale Preston
MCAD C#
MCSE, MCDBA


"weird0" wrote:

> Can i create Command,Connection objects once inside a class
> constructor and use them again and again by changing their values and
> destroy them instead of creating objects everytime in a class member
> function.......
>
>

I throw my hat in with Dale on this one. Sometimes you really do need
to do some long-running operation in a constructor, but you should
avoid it if you can.

If there is some object that you want to use over and over in your
class, and it takes a long time to build, you might think about using
lazy construction: initialize it to null, and then the first time you
need it, construct it.

On Feb 20, 2:56 pm, Dale <dale0...@nospam.nospam> wrote:
> And constructors are not a good place for that type of code. Constructors
> should be used to create the object and as little other work as is possible.
>
> "weird0" wrote:
> > Can i create Command,Connection objects once inside a class
> > constructor and use them again and again by changing their values and
> > destroy them instead of creating objects everytime in a class member
> > function.......

HI,

"Dale" <(E-Mail Removed)> wrote in message
news:CED089FE-D206-43CD-9AEC-(E-Mail Removed)...
> And constructors are not a good place for that type of code. Constructors
> should be used to create the object and as little other work as is
> possible.

Yes, but if the info to create the instance is in a DB you may need to get
it from there

On Feb 20, 11:21 pm, "Bruce Wood" <brucew...@canada.com> wrote:
> I throw my hat in with Dale on this one. Sometimes you really do need
> to do some long-running operation in a constructor, but you should
> avoid it if you can.
>
> If there is some object that you want to use over and over in your
> class, and it takes a long time to build, you might think about using
> lazy construction: initialize it to null, and then the first time you
> need it, construct it.
>

Bruce,

I concur. If you're just initializing IDbConnection or IDbCommand
objects then fine. But, once you call Open or ExecuteReader or
whatever it immediately goes from minimal work to a significant time
consuming operation. That's work that may not be obvious to the
developer since the constructor doesn't have a descriptive name. If
the semantics of the class require a signficant operation for
instantiation then create an adequately named static factory method
that clearly describes what the operation might do.

I've brought up the example of the StreamReader before as something
that does not adhere to the framework design guidelines. It's
constructor will actually open a file, but no where in the
documentation is that made explicitly clear. To be fair, it can be
implied from looking at the exceptions it throws, examples, or by
noticing that the class doesn't have an Open method, but wouldn't it
have been better to just create a static StreamReader.Open method
which clearly indicates that a potentially significant operation is
happening?

Brian

In "Framework Design Guidelines" (Abrams, Cwalina et. al.) they agonize over
the fact that some very early "1.0" design decisions were vritually
impossible to fix in later versions because the amount of breakage would have
been unacceptable. I suspect your example is one of them.
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net




"Brian Gideon" wrote:

> On Feb 20, 11:21 pm, "Bruce Wood" <brucew...@canada.com> wrote:
> > I throw my hat in with Dale on this one. Sometimes you really do need
> > to do some long-running operation in a constructor, but you should
> > avoid it if you can.
> >
> > If there is some object that you want to use over and over in your
> > class, and it takes a long time to build, you might think about using
> > lazy construction: initialize it to null, and then the first time you
> > need it, construct it.
> >
>
> Bruce,
>
> I concur. If you're just initializing IDbConnection or IDbCommand
> objects then fine. But, once you call Open or ExecuteReader or
> whatever it immediately goes from minimal work to a significant time
> consuming operation. That's work that may not be obvious to the
> developer since the constructor doesn't have a descriptive name. If
> the semantics of the class require a signficant operation for
> instantiation then create an adequately named static factory method
> that clearly describes what the operation might do.
>
> I've brought up the example of the StreamReader before as something
> that does not adhere to the framework design guidelines. It's
> constructor will actually open a file, but no where in the
> documentation is that made explicitly clear. To be fair, it can be
> implied from looking at the exceptions it throws, examples, or by
> noticing that the class doesn't have an Open method, but wouldn't it
> have been better to just create a static StreamReader.Open method
> which clearly indicates that a potentially significant operation is
> happening?
>
> Brian
>
>