2

日付 私が興味を持っている特定の例を作成しました - しかし、同じカテゴリに分類される他のビットのデータがあります: 漠然と重要なエンティティについて取得したいデータです。

ビジネス ロジック (BL) とデータ アクセス レイヤー (DAL) のどちらが最適ですか?

これまで、テーブルへの挿入時に作成された日付を入力するために SQL Server に依存していましgetdate()たが、BL でこれをもっと行うべきかどうか疑問に思い始めています。

参考までに - これは主に、BL で (ユーザー入力に基づいて) オブジェクトを作成し、DAL でそれを起動する Web ベースのシステムで行われています。 (したがって、オブジェクトの作成時に BL で使用するためにオブジェクトに「作成日」プロパティを設定することは問題ではありません)。

おそらく3番目のオプションがあります-Marr75の回答を読んだ後、それを2回記録すると、いくつかのシナリオで役立つ可能性があることがわかりました（両方の場所で1回）。データレイヤーで一貫した日付/時刻の利点が得られますが、参照するBL駆動の値もまだあります-ユースケースに依存すると思います。ただし、このオプションにはリスクがないわけではありません。間違った日付を間違ったものに使用し始める可能性があります。

4

2 に答える 2

1

私は常に DAL に投票します。データベースを超えたレイヤーからの日付と時刻に依存することは、過去に私にとってバグの原因でした。ほとんどのセットアップでは、データベースの一貫した日付と時刻が保証されている可能性が高くなります。時刻同期の問題 クライアント - サーバー、さらにはサーバー - サーバーは厄介で、複製が困難で、修正が困難な問題を引き起こしています。

于 2010-08-31T02:12:37.747 に答える
0

はい。

おそらく、作成日と最終アクセス日を BL に設定する習慣を身につけてください。次に、DAL で、これらのフィールドの null を常にチェックします。それらが null の場合は、オプションを検討してください。例外をスローするか、そのレイヤーでそれらの値を入力するだけです。挿入/更新前の一種のキャッチオール。

質問で説明したのと同じパターンがありました。次に、アプリケーションで UTC タイムスタンプを使用/消費することに直面し、その動作を BL および/または DL クラスに移動するだけでよいと考えました。はい、使用することもできましGETUTCDATE()たが、BL/DL にこのロジックを含める方が適切だと感じました。

于 2010-08-31T02:12:57.543 に答える