Question

Recently I have noticed about a subtle restriction in GridView's paging mechanism. Efficient paging, loading just requested page of data, is only possible with using DataSource controls like ObjectDataSource that means declarative data binding and is impossible when not using a data source and just from codebehind (MSDN describes it here).

Does this means ASP.NET is based on declarative programming not code behind? And it's better to do declarative programming by default?

Was it helpful?

Solution

Out of the box WebForms tries to steer you down the declarative path. You can get around that and actually write code, but WebForms makes it extremely difficult.

If you really want to have control then you should look into the ASP.NET MVC Framework.

OTHER TIPS

ASP.Net uses both: markup is declarative, code-behind is imperative.

You should favor a style that leads to more declarative code - building user controls, for example. But those controls will still need imperative code that tells them how to behave.

I ended up doing my own paging using the SQL ROWNUMBER function.

select * from
( select row_number() over (order by pk asc) as rownumber, * from ...)
where row_number between @a and @b

I ended up not going declarative at all - instead of feeding a datasource the parameters (which one could feasibly do) I just managed everything in the code-behind, set the datasource manually, built the pager by hand.

The reason I did it that way? A bug in 3.5's querystringfield parameter handling.

I could have probably handled the object data source with row_number, but you don't have to do anything declaratively if you don't care to.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top