ASP.NET是基于声明式编程的吗?
最近我注意到 GridView 的分页机制有一个微妙的限制。高效分页,加载刚刚请求的数据页面,只有使用 DataSource 控件(例如 ObjectDataSource)才可能实现,这意味着声明性数据绑定,并且在不使用数据源并且仅从代码隐藏时不可能实现(MSDN 对此进行了描述 此处)。
这是否意味着 ASP.NET 基于声明式编程而不是代码隐藏?默认情况下进行声明式编程更好吗?
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?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
开箱即用的 WebForms 试图引导您走上声明性的道路。您可以绕过这个问题并实际编写代码,但 WebForms 使其变得极其困难。
如果您确实想拥有控制权,那么您应该研究 ASP.NET MVC 框架。
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.
ASP.Net 使用两者:标记是声明性的,代码隐藏是命令性的。
您应该偏爱一种能够生成更具声明性的代码的样式 - 例如,构建用户控件。但这些控件仍然需要命令式代码来告诉它们如何行为。
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.
我最终使用 SQL ROWNUMBER 函数进行自己的分页。
我最终根本没有进行声明——而不是向数据源提供参数(这是可行的),我只是管理代码隐藏中的所有内容,手动设置数据源,手动构建分页器。
我这样做的原因是? 3.5 的查询字符串字段中的错误参数处理。
我可能可以使用 row_number 处理对象数据源,但如果您不介意的话,您不必以声明方式执行任何操作。
I ended up doing my own paging using the SQL ROWNUMBER function.
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.