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]]

Re: server control with lots of database interaction

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" <sebastianthegr eatful@gmail.co mwrote in message
news:4257ecab-6153-4dba-9840-0c1a0c508f46@t5 4g2000hsg.googl egroups.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]

Re: server control with lots of database interaction

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.