0

だから、私は、StructureMap を使用して、Repository モデルに続くこの Web ベースのアプリに取り組んでいます。

アプリケーションの 1 つの側面により、ユーザーはファイルをアップロードおよび管理できます。

これらのユーザー ファイルの保存/削除の管理は、どこのどの層が担当する必要がありますか?

ビジネスレイヤー、またはデータアクセスレイヤー...?

それは、何らかの理由で、簡単な答えではないようです...

歴史的には、GUI で平手打ちしただけでしたが、よりプログラム的に正しくなるように努力し、これらのサービスを処理する方法を再考しました。たぶん私は自分の質問に答えただけです...

4

5 に答える 5

2

別のレイヤー「ストレージ アクセス レイヤー (SAL)」を作成します .... DAL からファイル情報を取得し、それを SAL に渡すと、SAL は正しいファイルを返します ....もしいつかウェブ ホスティングから Amazon ウェブ サービスに切り替えたらstorage 、SAL のクラスを変更するだけで、DLL をプラグインしてすぐに使用できます..ユーザーは以前と同じ方法でファイルをアップロードするため、UI は変更されません.....ビジネスルールは同じように適用されます以前はBLLは変更されていません....データベースは変更されておらず、ファイルの情報は以前と同じように保存されているため、DALは変更されていません....変更されたのはファイルにアクセスするためのプロトコルだけでした.... SALを変更する

于 2011-08-04T13:15:31.670 に答える
0

DALフルストップです。

ビジネス ロジックは、環境に IO 依存性を持つべきではありません。

それをビジネスロジックに入れると、次にその「ロジック」の一部を使用したいが、最終的にはファイル IO 権限のない環境になってしまい、乾杯することになります。

于 2010-12-08T02:16:38.273 に答える
0

私ならビジネス層に入れますが、私だったら、各ユーザーがアップロードしたファイルに関して DAL を呼び出すことになります。ユーザーがアップロードする各ファイルのファイル名と場所をデータベースで追跡します。

于 2009-02-05T21:56:53.727 に答える
0

System.IOである別の「プロトコル」を介して、更新またはクエリするファイルデータを検討したため、私はDALに入れました。

より具体的には、すべての基本を処理する FileManager クラスを作成し、いくつかの定数を配置して、開発環境と運用環境が大幅に異なるため、パスの場所を簡単に変更できるようにしました。

于 2009-02-05T21:58:46.093 に答える
0

Dillie-O - さらに、アプリケーションが IO から DB にファイルを保存するように切り替えた場合、DAL はより論理的な場所です。ある程度の柔軟性...

于 2009-02-05T22:02:36.630 に答える