is a datarelation the way to go?

microsoft.public.dotnet.framework.adonet

13 Apr 2006 8:50 AM

Duncan A. McRae

Greetings:

I am working on a small application to learn the .NET 2.0 framework
better (ASP.NET and C# against SQL Server 2005). I have chosen as my
project a web-based expense-tracking tool. When a person logs in their
account details (currently only one or two fields) are loaded into a
Session object.

####--> In "classic" ASP (cASP), sessions were to be avoided for
performance and scalability. I'm using cookieless Sessions, where data
appears to be hidden as form variables. Should I still avoid using
Sessions? From a memory perspective I would expect so.

Upon login the user is taken to a summary page. That summary page
shows
- projects the account is involved in
- any counterparties to those projects (think "joint venture")
- the balance, DR or CR, with respect to each counterparty

Counterparties are peers (another record in the Account table). I have
tables for Account, Project, accountJoinProject. Account1 is related
to project1, project1 is related to account2, therefore account1 and
account2 are counterparties.
- An account will track 1..3 projects, in extreme cases 1..6 (1..n is
permitted).
- A project will have 1..2 counterparties, in extreme cases 1..3 (1..n
is permitted).
- A project will have 1..n expenses associated. I'm only interested
in "SUM(expense) GROUP BY counterparty" on the summary page.

####--> When the user logs in, is the dataRelation object, to connect
Account--accountJoinProject, accountJoinProject--Project and
accountJoinProject--Account again a wise approach or a waste of time
and processing power? Since this isn't a situation where I'm pulling
in thousands of records I don't want to return the whole tables and
then filter on the accountID after the fact, but I haven't seen a WHERE
clause in any of the dataRelation examples I've seen.

####--> Once I have the few elements I'm interested in, I'd like to
convert my data to XML or other stream-friendly format, encrypt it and
put it into a hidden form element. I would rather NOT keep this data
in the Session. Is this a reasonable approach, or am I begging for
trouble?

As you can tell by the time at which I'm posting this, I may have
overlooked the obvious; please forgive me if this is the case. I
really appreciate pointers to information and docs so I can understand
my questions completely.

Thank you;
Duncan

13 Apr 2006 9:48 AM

Cor Ligthert [MVP]

Duncan,

Feel free to post to this newsgroup as often you want. I give you however
more change in the newsgroups.

Microsoft.public.dotnet.framework.aspnet
and/or
Microsoft.public.dotnet.security

This newsgroups handles databases etc.

To give you some little things to overthink.
There is a viewstate with wich you can sent everytime the data to the
client, the problem with that is that it eats of course your linespeed.

There is beside the session which belongs to a user the shared/static class
and the cache which belongs to all users. I don't know if that helps you in
stead of a session to save memory.

However I assume that in the two newsgroups I have given you they can help
you much better than me in this.

Cor

Show quote

"Duncan A. McRae" <google.***@mcrae.ca> schreef in bericht
news:1144918238.108063.266850@i39g2000cwa.googlegroups.com...
> Greetings:
>
> I am working on a small application to learn the .NET 2.0 framework
> better (ASP.NET and C# against SQL Server 2005). I have chosen as my
> project a web-based expense-tracking tool. When a person logs in their
> account details (currently only one or two fields) are loaded into a
> Session object.
>
> ####--> In "classic" ASP (cASP), sessions were to be avoided for
> performance and scalability. I'm using cookieless Sessions, where data
> appears to be hidden as form variables. Should I still avoid using
> Sessions? From a memory perspective I would expect so.
>
> Upon login the user is taken to a summary page. That summary page
> shows
> - projects the account is involved in
> - any counterparties to those projects (think "joint venture")
> - the balance, DR or CR, with respect to each counterparty
>
> Counterparties are peers (another record in the Account table). I have
> tables for Account, Project, accountJoinProject. Account1 is related
> to project1, project1 is related to account2, therefore account1 and
> account2 are counterparties.
> - An account will track 1..3 projects, in extreme cases 1..6 (1..n is
> permitted).
> - A project will have 1..2 counterparties, in extreme cases 1..3 (1..n
> is permitted).
> - A project will have 1..n expenses associated. I'm only interested
> in "SUM(expense) GROUP BY counterparty" on the summary page.
>
> ####--> When the user logs in, is the dataRelation object, to connect
> Account--accountJoinProject, accountJoinProject--Project and
> accountJoinProject--Account again a wise approach or a waste of time
> and processing power? Since this isn't a situation where I'm pulling
> in thousands of records I don't want to return the whole tables and
> then filter on the accountID after the fact, but I haven't seen a WHERE
> clause in any of the dataRelation examples I've seen.
>
> ####--> Once I have the few elements I'm interested in, I'd like to
> convert my data to XML or other stream-friendly format, encrypt it and
> put it into a hidden form element. I would rather NOT keep this data
> in the Session. Is this a reasonable approach, or am I begging for
> trouble?
>
> As you can tell by the time at which I'm posting this, I may have
> overlooked the obvious; please forgive me if this is the case. I
> really appreciate pointers to information and docs so I can understand
> my questions completely.
>
> Thank you;
> Duncan
>

13 Apr 2006 12:31 PM

Duncan A. McRae

Cor, I appreciate your response and your pointers. Is "danke" the most
appropriate response?