server control with lots of database interaction

[Seb]

I want to develop a server control which query a database several
times. The thing is I cant just include the result of a linq query as
a datasource since I need to query several times and work on the
results... and perhaps query some more.
Should I include a reference to my datacontext class?

I also want it to act a bit like asp:Login in the sense that it
creates a database if one isn't present or create the need tables if
one is.

Can someone point me in the right direct either by some hints or by a
url?

best regards,
seb

[Alvin Bruney [ASP.NET MVP]]

You shouldn't couple your control to the database. You should call into some
business layer instead. Let the business layer call into the database that
way you don't implement a brittle control that falls over dead when the
database schema changes etc.

--

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
-------------------------------------------------------
"Seb" <se******************@gmail.comwrote in message
news:42**********************************@t54g2000 hsg.googlegroups.com...

I want to develop a server control which query a database several
times. The thing is I cant just include the result of a linq query as
a datasource since I need to query several times and work on the
results... and perhaps query some more.
Should I include a reference to my datacontext class?

I also want it to act a bit like asp:Login in the sense that it
creates a database if one isn't present or create the need tables if
one is.

Can someone point me in the right direct either by some hints or by a
url?

best regards,
seb

[Seb]

On 13 Jul., 18:13, "Alvin Bruney [ASP.NET MVP]" <vapor dan using hot
male spam filterwrote:

You shouldn't couple your control to the database. You should call into some
business layer instead. Let the business layer call into the database that
way you don't implement a brittle control that falls over dead when the
database schema changes etc.

Makes sense, thanks for the info.