What data layer to use for performance?

Hi.
I did not post this in database forum because the data will run on an asp.net site.
I have 3 solution in my mind and i would like some opinions.
What i want to do is create a parent-child relationship on 2 controls.
A listbox and a textbox.
I will populate the listbox with data(this is taken care of so ignore) and what i want to do is when i click on an item in the listbox then the textbox to show it's joined related item(one item only).
This is not a problem in windows forms app but in asp, since i'm new i don't know what would be better for a faster retrieval on the page.
So the 3 options i have in mind are:
1)DAL.The standard create a query and let one @parameter wait for the id.
2)ADO.NET with possibly an sqldatasource.In standard forms i would have chosen simple ado.net but in asp?So either constantly open,close the db and retrieve the item or use an sqldatasource and chance the parameter.
3)Asynchronous handler page.Bind the textbox to an asynchronous page that contains the connection and expect the @id parameter.

I admit that i'm not fond of DAL but if it will boost speed then i will use it.But i have a though that says that simple ADO will be faster.

Thanks for any comments made :)

Hey,

To be clear, using a DAL, or rather an multi layer architecture, is not always about performance, but rather about the logical separation of code into relevant areas, with clear responsbilities given to each layer. i.e. presentation, business logic and data access.

In all honesty, I would advice against the use of the SqlDataSource. This control is fine for creating proof of concept applications, to ensure that something is going to work, but if you try and bring this into a fully fledged application, you are likely to run into problems.

If I were you, I would go with more of a combination of 1 and 3. Write the DAL code to accept the id that you are interested in, and return the information. On top of that, you can choose to Cache results so that on subsequent requests for the same information, within a short period of time, come from the Cache, rather than hitting the database again. Then, you can either use AJAX, or perhaps jQuery with a PageMethod, to get this information back to the client, without having to do a full page post back.

Gary

Hmm.
I was thinking if i have Ajax so no postback, maybe i put the data inside a datatable-dataset and use it.So one call with all the info.The rows would be from 1 to 4-500.Here i don't mind about dataset lose the data after a full refresh.
I don't know if i incorporate DAL as i see the code but i'll give it another view today.

If it is a 1 to 1 relationship between an Item in the listbox and the related Data you will display in the textbox then you could set the listbox text = Item and value = Data all in one ADO method then on client click use javascript to show the Data in the textbox > no postback, callback needed.

A rough example of markup

Code:

---


<script type="text/javascript">
  clientJS(){
    //set value of textBox to selected value of listbox
}
</script>

<input id="myTextBox"....../>

<select....onclick="clientJS()">
  <option value="relatedData">Item Text</option>
  etc....
</select>

---

How you handle your data on the server is personal choice normally dictated by web app requirements. Don't get into the habit of using the sqlDataSource, It's just as easy to write a little ADO. If you don't want to do a DAL (as Gary says performance is not the primary focus of a DAL) just use a dataReader for optum performance or a dataSet if needed.

Also don't worry about about the performace when lots of users bash away getting data from the servers, servers are designed for this. If you have very limited resources or a huge amount of users then you have to start getting serious about memory/app_pool usage.

Thanks.
I'm using event of the listbox.
This is because i couldn't make the DAL work in asp.
I mean i create a private dataset as the DALdataset and then i fill it with the tableadapter. The data is lost everytime from the dataset when i do p.e. a selectedindexchanged from the listbox.
I don't know, maybe i haven't use DAL for long but i remember that if i created a withevents dataset in windows.forms then i could never loose the data.
Anyhow, i have a listbox and i use the databinding and selectedindexchange events.The data is populated once with simple ado and i put it in a hidden gridview.After that i do a search on listbox vs gridview.
As i've said i couldn't make the DAL dataset to have constant data so i use the gridview.
Any thoughts?

to persist an object across postbacks you need to store it somewhere like viewstate, session etc. With web app once a page has finished processing on the server all objects are destroyed. The gridview uses viewstate to persist data and handle events passed from client to server. So instead of using the grid you could do

viewstate("myDataSet") = yourDataSet

then after postbacks get it from viewstate

dim ds as dataSet = viewstate("myDataSet")

Viewstate only exists for the page you create it on.

Lastly the example I showed was HTML etc in the browser (client) as apposed to server side events such as dropDowwn selectedindexchanged.

Just side stepping the current question slightly...

If you are looking for a complete sample on how you can implement a true multi-layer application, including caching etc, I can think of no better sample than this one:

http://thebeerhouse.codeplex.com/releases/view/127

It takes a bit of time to understand, but once you do, you will have all the concepts that you need.

Gary

Thanks Gary i'll read it when i have some time.
Brin a dataset passed on viewstate? :cry:
If i am to create and update the viewstate then i think i'll just let the gridview to do the work.
Thanks.

Depending on the type of information that I was retrieving, i.e. how volatile the data, I would be quite happy putting the result set into the Cache, and retrieving it from there.

Gary

Well, then i shouldn't feeling uncomfortable that i use 2 gridviews as data storage? :o

Hmmm, I am confused?!?

A GridView is for displaying the data, not for storing it. Are you re-binding the GridView each time? Or are you relying on ViewState keeping the information there?

Gary

Well.
See the problem is that the code is over 2500 lines so i just decided to let the gridview have a viewstate instead of constantly finding and bind- re bind datasets on the viewstate.
As i've said.Im used to just have an initial Private withevents for data and i'm fine.But in Asp i'm having a really hard time :(

I think in this instance, the "hard time" comes from you previously allowing Visual Studio to do things for you, which isn't always the best approach. In this situation, you are now having to learn how to do things properly, and that is where the problems are coming in.

You are saying that there are 2500 lines of code just to bind your GridView? Really? Why so much?

Gary

Not 2500l lines of code for a bind LOL, just one line.2500 lines of code with binding,asp,events etc.
Well i just used VS to automate binding on a couple of listboxes and also the calendar sample was using an Sqldatasource, so what i was to do? :p
You know the funny part is that they wanted a completely different calendar from what i was making so now i'm having a hard time.I didn't bother to use any gridviews or datasets for storage before but the re-design would have taken(and if doable) a couple of weeks, so i had to think something more "dirty" to fasten things up and make it work (:sick:). If i had time i would have made almost all data manually, but...

P.S My binding record must have been when i first started vs 2003.I think it took 100 lines to make a dataset :cry: :bigyello:

Ha ha.

Fair enough, I will let you off :)

You quite often get into situations where you have to do something a certain way, even though you know it's not the best way, simply because of time constraints etc. The important thing is in knowing that it isn't quite right, and not let yourself get into the habit of doing it.

Gary

Absolutely correct.
But time is an issue here.
If anything,i will mark this up as "redesign" for future use.
Thanks.

Yip, put it onto the long list of jobs that you will do if you get a spare minute. My list is huge!!! :D