我正在处理的Web应用程序的一部分是显示从管理到1 ... n个用户的消息的区域。我有一个DataAccess项目，其中包含LINQ to SQL类，还有一个网站项目，即UI。我的数据库如下所示：

用户-> MessageDetail <Message <MessageCategory

MessageDetail是一个联接表，还包含一个IsRead标志。

消息列表按类别分组。我在页面上有两个嵌套的ListView控件-一个输出组名，而另一个嵌套在内部，绑定到MessageDetails并输出消息本身。在列出消息的页面的代码后面，我有以下代码：

protected void MessageListDataSource_Selecting(object sender, LinqDataSourceSelectEventArgs e)
{
    var db = new DataContext();

    // parse the input strings from the web form
    int categoryIDFilter;
    DateTime dateFilter;
    string catFilterString = MessagesCategoryFilter.SelectedValue;
    string dateFilterString = MessagesDateFilter.SelectedValue;
    // TryParse will return default values if parsing is unsuccessful (i.e. if "all" is selected"):
    // DateTime.MinValue for dates, 0 for int
    DateTime.TryParse(dateFilterString, out dateFilter);
    Int32.TryParse(catFilterString, out categoryIDFilter);
    bool showRead = MessagesReadFilter.Checked;

    var messages =
        from detail in db.MessageDetails
        where detail.UserID == (int)Session["UserID"]
        where detail.Message.IsPublished
        where detail.Message.MessageCategoryID == categoryIDFilter || (categoryIDFilter == 0)
        where dateFilter == detail.Message.PublishDate.Value.Date || (dateFilter == DateTime.MinValue)
        // is unread, showRead filter is on, or message was marked read today
        where detail.IsRead == false || showRead || detail.ReadDate.Value.Date == DateTime.Today
        orderby detail.Message.PublishDate descending
        group detail by detail.Message.MessageCategory into categories
        orderby categories.Key.Name
        select new
        {
            MessageCategory = categories.Key,
            MessageDetails = categories.Select(d => d)
        };

    e.Result = messages;
}

这段代码可以工作，但是在LinqDataSource控件的代码后面贴上这样的巨大LINQ语句并不适合我。

似乎我仍在将查询编码到用户界面中，只是现在是LINQ而不是SQL。但是，我觉得在L2S类和UI之间建立另一层将削减LINQ的某些灵活性。减少我们为获取数据而编写的代码量不是全部目的吗？

有没有我可能看不到的中间立场，还是我只是误解了应该使用LINQ to SQL的方式？意见将不胜感激。

解决方案

回答

无论使用LINQ，我都认为将演示代码与数据库相关代码混合并不是一个好主意。我将在LINQ查询之上创建一个简单的DB抽象层。我认为LINQ只是一种方便的工具，不会对传统的应用程序设计产生严重影响。

回答

我们所有的LINQ查询都应该在业务逻辑类中，而与ADO之类的旧方法相比则没有变化。

如果我们是纯粹主义者，则应始终从业务类中的方法返回List(of T)，实际上，数据上下文仅对业务类可见。
然后，我们可以在用户界面中操作列表。

如果我们是实用主义者，则可以返回IQueryable对象并在用户界面中进行一些操作。