0

かなり一般的なアーキテクチャがあります。

データベース

リポジトリ層

ビジネス オブジェクト

サービス層 - クライアントに DTO を提供します

Web レイヤー (MVC)

リソース、特に画像やポッドキャスト (例: http://media.mysite.com/podcasts/ ) への一般的なパスがいくつかあります。プロパティを持つ静的ユーティリティ クラスを作成したい:

MySite.Utils.ImagePathUri

MySite.Utils.PodcastsPathUri

等

私の質問は: uri パスをどこに置くのですか? このユーティリティ クラスはどのプロジェクトに入りますか?

当初、それは簡単なことのように思えました: Web レイヤーです。それはウェブサイトです。他のレイヤーに知られることなく、サイトの URL を変更できるはずです。

すべて順調でしたが、. . . そしてある日、私のサービスの 1 つが SyndicationFeed タイプを提供する必要がありました。SyndicationFeed には、部分的なファイル名だけでなく、完全な URI が必要です。ただし、サービスは完全なパスにアクセスできません。それとも彼らはすべきですか？

私はいくつかのことを自分自身と議論しましたが、確固たる立場を思い付くことができません:

  1. パスをサービス層に移動します。これにより、Web レイヤーがサービス レイヤーに緊密に結合されますが、最初から非常に緊密に結合されているため、おそらく問題ありません。
  2. パスをビジネス オブジェクトまたはリポジトリに移動します。私はこれが好きではありませんが、サービス層に入れることに前向きであれば、少なくともそれを検討する必要があります。
  3. SyndicationFeed をサービス レイヤー内で使用しないでください。Web レイヤーでのみ使用してください。問題は解決しましたが、SyndicationFeed はサービス レイヤーに属する必要があるようです。
  4. SyndicationFeed を破棄します。SyndicationFeed は、適切な XML を生成する PartialView を使用して MVC でより簡単に作成できます。ElementExtensions のような肥大化した抽象化をいじる必要はありません。私はこれが好きですが、多くの場所で SyndicationFeed を使用しているため、最も説明が必要な場所です。
  5. サービス レイヤーのシンジケーション フィードに偽の URI を提供し、それを Web レイヤーで変更します。ハックと言えますか？
  6. データベースにフル パスを入力します。最初は問題ないように思えますが、動的に生成された画像を取得するとすぐに壊れることに気付きます。
  7. 私には起こらない他の解決策。

あなたの考えは何ですか？Web リソース (画像、ポッドキャストなど) のユーティリティ クラスはどこに配置しますか? また、「Web レイヤー」と言う場合、SyndicationFeed の問題についてどう思いますか?

アップデート

結局、私は SyndicationFeed クラスを破棄することにしました。これにより、サービスおよびリポジトリ レイヤーにファイルへのパスを含める必要がなくなりました。ただし、問題は別の場所でも発生し、DI の使用、特に Ninject のような IoC は完全に理にかなっています。これらを共通のインターフェイスにまとめることも同様です。

SyndicationFeed、View エンジン、および Declarative が Declarative の方が優れている理由

私は SyndicationFeed を捨て、代わりに Razor を使用して必要な XML を作成しました。作成がはるかに簡単であるだけでなく、1000% 読みやすくなっています。私は、命令型コード (C#、VB など) を使用して XML を作成するのは、必要以上に難しいという意見に行き着きました。XML は宣言型であり、命令型ではありません。

代わりに、ビュー エンジン (Razor など) の宣言型構文は、命令型言語よりもはるかに扱いやすいと判断しました。

4

2 に答える 2

1

あなたの痛みが分かります。私も同様の状況にあり、URI を Web レイヤーからリポジトリ レイヤーに渡すことで解決しました。

私のプロジェクトではバインドに Ninject を使用しています。すでに Ninject を使用して接続文字列をリポジトリに渡しているので、パス文字列も渡すのは簡単なことでした。

その後、私のリポジトリはパス文字列をマッサージし、ビジネス オブジェクトに必要なプロパティを入力します。

これは適切ですか？わかりませんが、今のところ機能しています。解決策に完全に満足しているわけではありませんが、改善を試みる機会はまだありません。

他の人がこれにどのように対処したかを聞きたいです。

于 2011-08-11T18:14:31.047 に答える
1

同様の状況に直面したとき、私はそれにアプローチする最善の方法は、最上層にオブジェクトをもたらす構成インターフェースを定義することだと感じました。間にある各レイヤーは、より具体的なプロパティと操作でインターフェイスを改良します。

public interface IWebConfiguration 
{
    string RootImageUri { get; }
}

サービスは、それ自体で必要なものを追加します。

public interface IServicesConfiguration
{
    string SyndicationFeedUri { get; }
}

public interface IDatabaseConfiguration
{
    string ConnectionString { get; }
}

最終的に、すべてのインターフェースを接続する特定のオブジェクトを Web 層に実装させました。醜い？多分。そこにisaへの呼び出しといくつかのキャストがあったことを認めます。

ただし、各レイヤーに強く型付けされたインターフェイスを渡すことができました。私の意見では、構成ファイルから単純な古い文字列を取得するために一連の呼び出しを行うよりも優れていました。また、各プロパティはレイヤーに固有であり、集約オブジェクトが渡されていたため、構成を一度ロードするだけで済みました。

于 2011-08-11T19:14:01.617 に答える