看到园友的一篇文章，说在一些企业门户站点里，我们经常会去根据需求变更来修改数据绑定的筛选条件，深有同感。而诸如企业门户这些场景一般也不用考虑什么性能之类的非业务要求，尽快的完成业务变更和尽可能少的减少网站编译更新次数却是网站技术支持团队的核心竞争力之所在。
不妨设想一下，如果用Store Procedure+DAL+BLL 写好的一个列表查询，如果要适应查询条件变更，则要动的地方恐怕很多，还需要重新编译，再把一堆dll更新上去。。。
看了“活跃的毛虫”兄弟的代码，本人也有所感悟，在此也分享一种更加“动态”的绑定方法：
大家知道，在.NET3.5以来，与Linq同时也提供了很多针对泛型集合的扩展方法，如Where/Take/OrderBy...等等。
在这样的场景中， 这些扩展方法也可以大有用场。比如下面的例子：
<p>
<asp:GridView ID="GridView1" runat="server" DataSource='<%#GetNewsData().Where(r=>r.Subject.StartsWith("aaa"))%>'>
</asp:GridView>
</p>
public partial class About : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
DataBind();
}
public static List<NewsData> GetNewsData()
{
List<NewsData> result = new List<NewsData>();
result.Add(new NewsData() { Subject = "aaaa" });
result.Add(new NewsData() { Subject = "bbb" });
result.Add(new NewsData() { Subject = "aa22" });
result.Add(new NewsData() { Subject = "aa1" });
return result;
}
public class NewsData
{
private string subject;
public string Subject
{
get { return subject; }
set { subject = value; }
}
}
}
更加动态的实现了查询条件在aspx页内定义。
需要注意的是：
这种写法不适用于大型应用，每个页面实例的CPU和内存开销都不小。 而且对原始数据集合（未经筛选的数据集），最好能够做到一定的缓存，从减少不必要的IO开销。