SouthSpawn posted on Monday, January 12, 2009
I am using LINQ to SQL to make "Stored Procedure" calls to the database.
I am populating my BO's with the results that my stored procedure returns back to me.
Here is the question.
I am binding my BO's to a asp.net GridView control.
I have "AutoPaging" on.
It works with no problems.
What I am concerned with, is that my stored procedure might return back 10,000 + records at some point.
Do I need to do manual paging, such as passing a page size and page index to my stored procedure and let it page on the server.
Or will the GridView control handle this for me?
Thanks
RockfordLhotka replied on Monday, January 12, 2009
You can do paging in different places:
- In the grid control (worst performance, easiest to implement)
- In the business list object (worst performance, harder to implement)
- In the DataPortal_Fetch() method (good performance, fairly easy to implement)
- In the database or SQL statement (best performance, potentially hard to implement)
All these are supported by CSLA. If you are getting 10k items, I'd look at option 4.
The CSLA .NET Version 2.1 Handbook has a section directly addressing these options.
SonOfPirate replied on Monday, January 12, 2009
I would agree with Rocky. If you are dealing with large recordsets, then implement paging as close the data as possible to eliminate as much excess data being transfered as possible. Even if you are dealing with a single-tier deployment where the UI, business logic and database exist on the same system there is a performance hit communicating with the database. Split these across a network and the impact is more severe. The more you can do to reduce the amount of data you transfer to only the data you actually need, the better. In my case, I'll pass in pageIndex and pageSize parameters to the sprocs where I implement paging and let SQL do the work.
