Further My Understanding of Pages/DAL

[Shaggy Hiker]

As I am working my way into the web world, I'm finding it considerably different from what I am used to. The two other threads I have in here show a few steps along the way, but with each one I made progress. So, I decided to test out some of my understanding of how things work, and I'm not sure that I quite have a question, but somebody can probably clarify things.

I created a dll with some business objects that exposed some functionality of a DAL layer. The details of that are pretty much irrelevant, which is the point behind using a BO/DAL in a dll. Then, over in the code, I created an instance of the BO object like so:

Private ContactsSource As New HILISupplier.HILIProvider

This is what I might do in a WinForms app with the expectation that creating one form level variable it would persist. I see that's not really the way things work in ASP. That line is in a class called WebForm4 for whatever reason (mostly because that was fine with me). I was thinking that this class existed on the server side and persisted. It appears that it does, indeed, exist on the server side, but an instance is created on every postback. Is that right?

The follow-up to that is: Does anything persist? Perhaps it can't persist in a web world, since it might be impossible to know when it can be discarded. I can live with that, though it makes some of the things I've done appear kind of silly since they were based on efficiencies that simply won't exist. Still, I'd like to be clear on this point. I can come up with much simpler code than I have if there isn't anything persisting on the server side while I interact with a web page.

[sapator]

I can think of 4 things right now that persist.
Sessions
Viewstate
Cookies
and hidden fields.

[szlamany]

Each web request starts a thread running that consumes the code. It's always a new instance of that code.

For each user - and sometimes very close in time posts by different users!

I persist very little - here's me persisting the "parameters" of a stored procedure so I do not always have to "gather them" from the SQL database.

    Dim g_prmSP As New Dictionary(Of String, SqlParameter())
.
.
.
        With Application
            .Lock()
            .Item("g_prmSP") = g_prmSP
            .UnLock()
        End With
.
.
                    With Application
                        .Lock()
                        If .Item("g_prmSP") IsNot Nothing Then
                            g_prmSP = DirectCast(.Item("g_prmSP"), Dictionary(Of String, SqlParameter()))
                        End If
                        .UnLock()
                    End With

My collection of sqlparameters is now saved by the IIS "process" - the service that never stops running.

Although it does stop running if the server reboots or the service goes through some kind of restart (and it can do that automatically also).

In those cases PERSISTENCE is not guaranteed - but that's no-harm-no-foul in my situation.

btw - Application is just a level above Session...

You would have to serialize your class in order to persist it.

You would have to tag it in some structure so it's known to "who it is owned by" - since you have many users hitting that same IIS-service.

I guess Session is supposed to take care of that - but I would worry about someone opening two web pages from the same browser hitting the same web page...

VIEWSTATE - yuk - that ships the serialized class to the web page so it can be shipped back on post back - what a failure of the ASP.Net model imo...

[Shaggy Hiker]

Cool, then I can do this more simply than I had been doing it. I just hadn't understood that before. I'm going to leave this open for a bit longer, though.

[sapator]

Yep, the possibilities are unlim...Errr actually quite limited.
You can also have a look at caching, that i forgot about. http://msdn.microsoft.com/en-us/libr...=vs.71%29.aspx
And what is wrong with viewstate? Use it and see your page size grow! Anyhow many controls in asp.net are using viewstate behind the hood (can be deactivated of course but how many here bother?) but szlamany is on Jquery level (as i hope to go to) so it's logical to react like this. I personally use viewstate here and there if i want to store small values, instead of locking the application (and possibly forget to unlock it, for that i can be sure about me :P ). You can store p.e. the id value of an SQL row. That won't make any difference even in a 14440 modem. On the other hand, if you try to store p.e. a datataset then your are asking for it.

[Shaggy Hiker]

I might keep a single value in the viewstate, we'll see.

What does p.e. stand for? I can come up with a few possibilities, but I think I had best ask.

[szlamany]

Viewstate for small single values - makes sense. No different then having a hidden column in a grid for the PK of the record being updated - all cool imo.

But by all means be educated - use FIREBUG (or whatever flavor you prefer) to watch the GETS and POSTS - be aware of the time for each - and examine the return values for size (or did I mean to say "bloat"?)

You also have to start thinking a bit differently. The BO/DAL for a winform is usually serving just that winform being run by a single user. Although you could certainly tier up to a remote-DAL serving many WINFORMS on a network...

My point being is that you are abstracting the BO/DAL from the winform UI for your programming convenience more than anything else.

In IIS you have to realize that you are running threads for multiple-overlapping calls from many clients at the same time - you are almost now forced to actually live in some remote-BO/DAL world.

I've read many books on n-tier-yadda-yadda and how to implement said solutions (or at least tried to finish these books).

Since the BO/DAL is no longer just for your programming pleasure - what are you actually trying to accomplish with it? What is it's primary goal?

I'm curious to see how others who have moved from winform to webform have adapted those old classes that abstracted their data...

[sapator]

Par exemple , French for, for example. No harm to keep a single value in viewstate. Just to be clear, if you keep a value in the viewstate then you are reserving client page size, if you keep a value on session then your reserve server memory size, for cookies, well cookies, application lock, probably server memory but not sure on that one, caching in server memory but careful as it may be dropped.

[sapator]

About the classes. I am trying to webservice the hell out of them and crying every day from anger with WCF tries. Actually i haven't adopted any winform habits as i rarely used DAL with tableadapters. In the future i would probably be using tier but DAl/BLL but with straight asp.net as a backbone and web services WCF web api, whatever i find to be better - useful .

[szlamany]

Wow - thanks for the French lesson...

http://forum.wordreference.com/showthread.php?t=222101

Although I gotta say the Latin e.g. meaning exempli gratia - or for the sake of an example - is just prettier...

[sapator]

No, problem , lol.
It just stuck with me, years ago when i was learning French (did not finish them but, meh).

[brin351]

It's always debatable to use n-teir/bll/dal or simply ad-hock ado objects to get and bind data. Really I think it comes down to personal preference, size and complexity of the business, performance and scaling and maintaining the site. For a large complex business n-teir makes sense even at some performance cost, writing ad-hock t-sql at the page level may be inappropriate in this case. However on a page that gets heavy traffic going ad-hock and using a dataReader is a convenient way to get optimal performance. Which is better.... that's really case by case question.

IIS is designed for the "disconnected" client/server way websites function. As long as your aware of the overhead of asp.net controls, data objects etc you can use them to your advantage without problem. For example on say a management page that only several "managers/admins" can access having a datagrid with viewstate to take advantage of its built in paging/sorting/editing maybe the best solution because performance/scaling is not an issue.

Here's a couple of link on performance. The msdn one mentiones sqlDatasource but we never use that in production.

http://msdn.microsoft.com/en-us/libr...vs.100%29.aspx

http://www.codeproject.com/Articles/...eb-Application

[sapator]

Lol lol mega lol!!! I accidentally created a new full featured web site on VS2012! Lol LOL!!!!! That was the most ridiculous piece of page i have ever seen in my life! 100 Namespaces imported to show a single page!!
Ahhh good times good times!