open a db connection in a constructor ?

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Re: open a db connection in a constructor ?

sloan wrote:

Well, it is the DataAccessLayer , which talks to a database.
>
You notice I return an IDataReader, not a specific one. Thus I can swap it
out to a
SqlDataReader
OracleDataReade r
MySqlDataReader
OleDBDataReader
and it doesn't affect the business layer code at at all.

True. But you can only switch database - you can not switch to
XML files or some custom native stuff.

Return a collection of a custom class is a level higher at
the encapsulation scale.

See my other blog entry "multiple rdbms with the factory pattern" if you
want to see how to have the DAL support multiple databases in a non hacky
fashion.

That comes with .NET 2.0 ...

Arne

[Peter]

Re: open a db connection in a constructor ?

Arne Vajhøj wrote:

sloan wrote:

Well, it is the DataAccessLayer , which talks to a database.

You notice I return an IDataReader, not a specific one. Thus I can
swap it out to a SqlDataReader
OracleDataReade r
MySqlDataReader
OleDBDataReader
and it doesn't affect the business layer code at at all.

>
True. But you can only switch database - you can not switch to
XML files or some custom native stuff.

This is correct of course, but I thought the bigger "problem" was that
the data layer relies on the business layer to close the connection to
the database.

However, this is also recommended practice from Microsoft. For example,
at

http://msdn.microsoft.com/en-us/library/ms978496.aspx

one can read:

<quote>
Returning Data Readers As Outputs

The advantage of this option is as follows:

Performance. There is a performance benefit when you need to render
data quickly and you can deploy your Data Access Logic Component with
the presentation tier code.

The disadvantage of this option is as follows:

Remoting. It is inadvisable to use data readers in remoting scenarios,
because of the potential for client applications to hold the database
connection open for lengthy periods.
</quote>



/Peter

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Re: open a db connection in a constructor ?

Peter wrote:

Arne Vajhøj wrote:

>sloan wrote:

>>Well, it is the DataAccessLayer , which talks to a database.
>>>
>>You notice I return an IDataReader, not a specific one. Thus I can
>>swap it out to a SqlDataReader
>>OracleDataRea der
>>MySqlDataRead er
>>OleDBDataRead er
>>and it doesn't affect the business layer code at at all.

>True. But you can only switch database - you can not switch to
>XML files or some custom native stuff.

>
This is correct of course, but I thought the bigger "problem" was that
the data layer relies on the business layer to close the connection to
the database.

Not in my opinion.

However, this is also recommended practice from Microsoft. For example,
at

http://msdn.microsoft.com/en-us/library/ms978496.aspx

one can read:
>
<quote>
Returning Data Readers As Outputs
>
The advantage of this option is as follows:
>
Performance. There is a performance benefit when you need to render
data quickly and you can deploy your Data Access Logic Component with
the presentation tier code.
>
The disadvantage of this option is as follows:
>
Remoting. It is inadvisable to use data readers in remoting scenarios,
because of the potential for client applications to hold the database
connection open for lengthy periods.
</quote>

I disagree with it being best practice for the reasons mentioned
previously.

I agree that data readers perform well.

I am not quite sure about their remoting remark. Data readers
are not serializable, so they can not be send to the client. And
it is not obvious to me why the BLL-DAL-DB-DAL-BLL trip should
take longer depending on whether the PL is remote or local.

Arne

[Peter]

Re: open a db connection in a constructor ?

Arne Vajhøj wrote:

Peter wrote:

Arne Vajhøj wrote:

sloan wrote:
Well, it is the DataAccessLayer , which talks to a database.

You notice I return an IDataReader, not a specific one. Thus I
can swap it out to a SqlDataReader
OracleDataReade r
MySqlDataReader
OleDBDataReader
and it doesn't affect the business layer code at at all.
True. But you can only switch database - you can not switch to
XML files or some custom native stuff.

This is correct of course, but I thought the bigger "problem" was
that the data layer relies on the business layer to close the
connection to the database.

>
Not in my opinion.

In your opinion is it a "problem" at all, or is it ok to do this?

What I don't like about it is that (1) the connection to the database
is now open until the business layer closes it; and (2) the business
layer has to have knowledge of the data layer (and data source) to be
able to extract the data, either by use of column names or indices -
meaning the business layer has to have knowledge of the sql which
extracted the data in the first place, and my opinion is that this
knowledge belongs in the data layer, not the business layer.

But it *is* recommeded by Microsoft - so it could be it is a good way
to get data. Seems pointless to have a business layer though.

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Re: open a db connection in a constructor ?

Peter wrote:

Arne Vajhøj wrote:

>Peter wrote:

>>Arne Vajhøj wrote:
>>>sloan wrote:
>>>>Well, it is the DataAccessLayer , which talks to a database.
>>>>>
>>>>You notice I return an IDataReader, not a specific one. Thus I
>>>>can swap it out to a SqlDataReader
>>>>OracleDataR eader
>>>>MySqlDataRe ader
>>>>OleDBDataRe ader
>>>>and it doesn't affect the business layer code at at all.
>>>True. But you can only switch database - you can not switch to
>>>XML files or some custom native stuff.
>>This is correct of course, but I thought the bigger "problem" was
>>that the data layer relies on the business layer to close the
>>connection to the database.

>Not in my opinion.

>
In your opinion is it a "problem" at all, or is it ok to do this?

I would be willing to do it for smaller projects. Not for the
big stuff.

But remember: free advice is worth every cent you pay for it ! :-)

What I don't like about it is that (1) the connection to the database
is now open until the business layer closes it;

Not a serious problem in my opinion.

and (2) the business
layer has to have knowledge of the data layer (and data source) to be
able to extract the data, either by use of column names or indices -
meaning the business layer has to have knowledge of the sql which
extracted the data in the first place, and my opinion is that this
knowledge belongs in the data layer, not the business layer.

But I agree that this is a problem !

>
But it *is* recommeded by Microsoft - so it could be it is a good way
to get data.

MS is not perfect. And some things has been done giving priority to
being simple. The inheritance from Mort !

Seems pointless to have a business layer though.

That is another point. Someone preaches 3 layers as the only way. In
reality the number of layers should reflect the problem to be solved.
Some simple apps is actually fine with 2. But 3 to 4 are more common.

Arne

[Alvin Bruney [ASP.NET MVP]]

Re: open a db connection in a constructor ?

>But it *is* recommeded by Microsoft - so it could be it is a good way

>to get data.

No, it's not. It can't be, that recommender should lose their job
immediately. That programming rubbish is the reason there are so many
resource leaks in web applications. I have yet to come across a reason why
returning an open cursor to a caller is valid.

--

Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
Download OWC Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $15.00
Need a free copy of VSTS 2008 w/ MSDN Premium?

http://msmvps.com/blogs/alvin/Default.aspx

-------------------------------------------------------


"Peter" <xdzgor@hotmail .comwrote in message
news:#Okscxe4IH A.2072@TK2MSFTN GP04.phx.gbl...

Arne Vajhøj wrote:
>

>Peter wrote:

Arne Vajhøj wrote:
sloan wrote:
Well, it is the DataAccessLayer , which talks to a database.

You notice I return an IDataReader, not a specific one. Thus I
can swap it out to a SqlDataReader
OracleDataReade r
MySqlDataReader
OleDBDataReader
and it doesn't affect the business layer code at at all.
True. But you can only switch database - you can not switch to
XML files or some custom native stuff.
>
This is correct of course, but I thought the bigger "problem" was
that the data layer relies on the business layer to close the
connection to the database.

>>
>Not in my opinion.

>
In your opinion is it a "problem" at all, or is it ok to do this?
>
What I don't like about it is that (1) the connection to the database
is now open until the business layer closes it; and (2) the business
layer has to have knowledge of the data layer (and data source) to be
able to extract the data, either by use of column names or indices -
meaning the business layer has to have knowledge of the sql which
extracted the data in the first place, and my opinion is that this
knowledge belongs in the data layer, not the business layer.
>
But it *is* recommeded by Microsoft - so it could be it is a good way
to get data. Seems pointless to have a business layer though.