6

私が取り組んでいる Web アプリケーションの一部は、管理者から 1...n 人のユーザーへのメッセージを表示する領域です。LINQ to SQL クラスを含む DataAccess プロジェクトと、UI である Web サイト プロジェクトがあります。私のデータベースは次のようになります。

ユーザー -> MessageDetail <- Message <- MessageCategory

MessageDetail は、IsRead フラグも含む結合テーブルです。

メッセージのリストはカテゴリ別にグループ化されています。ページに 2 つの入れ子になった ListView コントロールがあります。メッセージを一覧表示するページの分離コードには、次のコードがあります。

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 ステートメントを貼り付けることは、私にはうまくいきません。

私はまだクエリをユーザー インターフェイスにコーディングしているようですが、今は SQL ではなく LINQ になっています。ただし、L2S クラスと UI の間に別のレイヤーを構築すると、LINQ の柔軟性の一部が損なわれると思います。データを取得するために記述するコードの量を減らすことが重要ではないでしょうか?

私が見ていない中間点の可能性はありますか、それとも LINQ to SQL の使用方法を誤解しているだけですか? アドバイスをいただければ幸いです。

4

2 に答える 2

5

すべての LINQ クエリはビジネス ロジック クラスにある必要があり、 ADO などの古い方法論から変更はありません。

純粋主義者の場合は、ビジネス クラスのメソッドから常に List(of T) を返す必要があります。実際、データ コンテキストはビジネス クラスからのみ見えるようにする必要があります。その後、ユーザー インターフェイスでリストを操作できます。

プラグマティストであれば、IQueryable オブジェクトを返し、ユーザー インターフェイスでいくつかの操作を行うことができます。

于 2008-09-24T22:46:45.073 に答える
1

LINQ に関係なく、プレゼンテーション コードとデータベース関連のコードを混在させるのは得策ではないと思います。LINQ クエリの上に単純な DB 抽象化レイヤーを作成します。私の意見では、LINQ は単なる便利なツールであり、従来のアプリケーション設計に深刻な影響を与えるものではありません。

于 2008-09-06T11:09:38.903 に答える