4

システムには、ユーザーが開始日と終了日を指定してアイテムを検索できるページがあります。これらは単純な日付です（時間コンポーネントなし）。ユーザーにとっては、終了日が包括的であることが最も直感的であるように思われます（したがって、その終了日のすべての項目も含めてください）。

ただし、のCreateDateアイテムには、データストアに時間コンポーネントが含まれています。実際には、これは、この時代を超越した終了日を翌日の0:00:00時間の日付に変換する必要があることを意味します。このようにして、次のクエリを記述できます。

SELECT *
FROM   Items 
WHERE  CreateDate >= @STARTDATE
AND    CreateDate < @ENDDATE

この終了日の変換は、次のコード行を記述するのと同じくらい簡単です。

endDate.Date.AddDays(1);

ノウ私の質問は：

このコードの最後の行のビジネスロジックを考慮してビジネスレイヤーに配置する必要がありますか、それともこの行を「モデルバインディングロジック」の一部と見なしてプレゼンテーション層に配置する必要がありますか？

それがBLに配置されるとき、これは、値が提供される方法がインターフェイス固有のものであるため、BLがプレゼンテーション層について認識していることを意味します。一方、操作はビジネスレイヤーでDTOとして定義されているため、このオブジェクトはプレゼンテーションレイヤーに便利なインターフェイスと見なすこともできます。

この質問は本質的に哲学的でさえあるかもしれません。なぜなら、これを見るにはおそらく複数の方法があり、実際の変換コードは簡単だからです。なぜそれを他のレイヤーではなく一方のレイヤーに配置する必要があると思うのか、興味があります。

アプリケーションのアーキテクチャがこの質問への回答に影響を与えるとは思わない。しかし、より完全な全体像を示すために、アーキテクチャはコマンドとクエリに基づいており、プレゼンテーション層はビジネス層によって処理されるクエリオブジェクトを作成します。PLコードは通常、次のようになります。

public Action Filter(DateTime start, DateTime end)
{
    var query = new GetItemsByStartEndEndDateQuery
    {
        StartDate = start.Date,
        EndDate = end.Date.AddDays(1)
    }

    var items = this.queryProcessor.Handle(query);

    return this.View(items);
}

または、可能な場合は、（MVC）モデルバインディングを使用して、コマンドとクエリオブジェクトを単純にモデルバインドします（これは非常に便利です）。

public Action Filter(GetItemsByStartEndEndDateQuery query)
{
    var items = this.queryProcessor.Handle(query);

    return this.View(items);
}

複数のユーザーが関与している場合（たとえば、WCFレイヤーとMVCレイヤー）、答えは変わりますか？

4

3 に答える 3

2

ビジネスレイヤーによって公開されるサービスのセマンティクスのコントラクトと、おそらくそのコントラクトの自動テストが必要です。

このコントラクトは、入力引数がどのように解釈および検証されるかを定義する必要があります。次に例を示します。

  • StartDate> EndDateの場合の結果はどうなりますか？
  • どの範囲の日付が許容されますか（たとえば、SQL Serverでは1753年1月1日より前の日付はどうですか）？
  • 入力パラメーターにゼロ以外の時刻コンポーネントを含めることができますか？その場合、時刻はどのように処理されますか（日付のみを切り捨てて使用します。呼び出し元に時刻コンポーネントが含まれている場合は例外をスローします。または、呼び出し元が時刻コンポーネントを指定できるようにします）。時刻コンポーネントを含む範囲）。
  • 範囲は排他的ですか、それとも包括的ですか？
  • タイムゾーンはどのように処理されますか（たとえば、種類=ローカル、UTC、または未指定の日付パラメーター）？

このコントラクトがプレゼンテーション層がユーザーからの入力を取得する方法と一致しない場合、プレゼンテーション層がコントラクトと一致するようにマッピングを行うことは問題ありません。

そしてもちろん、契約がデータアクセス層が日付範囲を期待する方法と一致しない場合、ビジネス層はデータアクセス層が期待するものにマッピングを行うことができます。

于 2012-09-12T12:43:07.313 に答える
1

私は通常、そのコード行やその他のコードをビジネス/ドメインレイヤーまたはドメインサービスに配置します。

そうであるかどうか：

endDate.Date.AddDays(1);

または：

endDate.Date.AddDays(3);

これはビジネス上の懸念事項であり、ビジネスレイヤーまたはドメインサービスに含める必要があります。適切に分離されたアプリケーションアーキテクチャがあれば、他の層（プレゼンテーション層など）に影響を与えることなく、ドメイン層を変更して再展開するだけで済みます。

于 2012-09-12T12:01:49.003 に答える
1

私にとって重要な点は、ページに入力された日付は、時間間隔の開始を表すか終了を表すかに応じて、さまざまな方法でタイムスタンプに変換する必要があるという事実です。つまり、相互に直接マッピングされる2つの異なる規則の単純な問題ではなく、実行するセマンティック変換があります。

私の意見では、そのような変換はビジネスロジックに属します。ただし、ユーザーのコンピューターがサーバーとは異なるタイムゾーンにある場合、問題はそれほど明確ではないことが判明する可能性があることに注意してください。

于 2012-09-12T12:20:02.483 に答える