Your Privacy Matters: We use our own and third-party cookies to improve your experience on our website. By continuing to use the website we understand that you accept their use. Cookie Policy
715
IgniteUI MVC Grid Pagination
posted

Hi,

I am new to Infragistics. I am developing an application for my company based on Service oriented architecture. The application consists of a generic service layer built using ASP.Net Web Api and the front-end is being built on MVC.Net 4.5 . The front end has no idea about the business logic except for two things :1)the models of entities placed in a 'Common' folder shared by all layers and 2) the name of the service method that should be called for the desired client-side page. The DAL uses ADO.Net to execute queries and return results in either DataTable format or in the form of an object model. We are not using Entity Framework.

QUESTION#1: The client-end is a separate MVC 4.5 project, The controller ReadsAsAsync the action result of the service and the respective view renders it on the browser.We dont want to use the rest full datasource property of Infragistic control because we need to wrap the request along with some other required data which is then passed along to the service layer. therefore we cannot use " .DataSourceUrl(Url.Content("~/api/products")) " directly because the generic service controllers needs some data in the header to process the request ( or maybe we could use it ? ). Can we do all that(i.e Add some Http Request headers with the request) and still bind the grid to the WebApi. Is this possible ?

QUESTIOn#2: Now there is a possibility that some pages might request for a huge amount of data in the form of a GET request from the service. In IgniteUI's grid, the remote pagination implements itself without writing any query to fetch a desired set from the whole SELECT statement.
From what i understand is that the Remote pagination automatically implements this remote pagination by requesting chunks of page sized rows from the .AsQueryable() data object which means that the SQL Server would have already execuated the "Select" query which might contain many rows of data and hence not an efficient way. So in a way the remote pagination is also getting data from the already executed query stored in the .AsQueryable() object returned from the service layer which we dont want or is this the normal procedure of pagination? Wont this still put load on SQL Server for selecting too many rows at one go.

Please point me in the right direction. Am I worrying about a potential issue or is this normal?

Parents Reply Children
No Data