I had some sessions with developers about getting list of data with Web-Services, they said it's depend on the type of the site, commerce, blog etc.
What is your opinion on the subject ? Is using a Web-Service for getting big list of data is a smart way performance wise?
You may look at how Apache Wicket list component has solved this issue.
Rarely you want to display the whole content of a big list. Only one page at a certain moment and links to other pages from the result set.
First time when you call the ws run the query, return a list of all IDs and sublist of records which will be displayed initially on the client. You can use size of the IDs list to create page links.
On the client you can use the list of IDs to build a request for some other page.
If you use some session management then the list of IDs can be stored on the server and request for a page can have only the page number and number of records per page.
ohhh.... we didnt here at work due to performance issues, that said it was for a CRM type application and getting a list of open cases from Line of Business Application had to return in under 3 secs. We ended up hitting the database directly.
SO i guess that is the answer what is the type off application and is a user involved?
If its system to system - we have those - orchestred by BizTalk - closed case list. Then its just availble system resources - so we scheduled those out of office hours to ensure no performance hit for both user groups
Personally I don't think it has all that much to do with the kind of application per se (although certainly user-facing apps will have different requirements than inter-machine ones, and some user-facing apps will tolerate lag more gracefully than others); really the question is, What's the best way to get my data to the client? which is one whose answer will invariably be some variation on, "Well, it depends."
For my part, I can say that for publicly oriented user-facing apps, generally speaking, "big lists" are to be avoided, or at least shied away from, not because they're inherently evil, but because they can impact the user experience (client apps may hang while retrieving or processing large data sets), they don't scale well (if your home page pushes down a meg of SOAP-encrusted stuff over the wire for every request, server-cached or not, you're going to run into trouble as traffic increases), and so on. Depending on how things go with the project, you may find you'll need to rewrite to support increased load or enhance lagging performance or responsiveness, which for service-oriented apps can be a significant, not-so-fun effort.
That said, I also write a lot of my own service tiers this way, on projects where responsiveness isn't of major importance to me (e.g., personal ones), or when I don't really expect all that much load, because they're quick to develop, deploy and maintain. Users do take the startup hit, but that hit can also be disguised by good design, and having the bulk of the data on the client, particularly when it doesn't change very often, can be handy.
So it's hard to say one way or another; sometimes it's fine, sometimes not -- "it depends." Without knowing more about your particular requirements, I'd probably suggest you go ahead and code up something simple using the big-list hammer, with real (or near-real) data, take some measurements, extrapolate them, and see how things look. You may find there's nothing to worry about, and the last thing you want to do is get bogged down in an unnecessarily complex design simply because a bunch of folks on StackOverflow told you that "big lists are bad." ;)