1

私は以下のようなサイト構造を持っています:

  • ProjectName.Core - エンティティ フレームワーク、コンテキスト、移行、インターフェイス、拡張機能、列挙型
  • ProjectName.Models - DTOS のみ
  • ProjectName.Repositories - リポジトリのみ
  • ProjectName.Services - リポジトリと対話する ninject を介してインスタンス化されたサービス、automapper 構成
  • ProjectName.Tests - 自明
  • ProjectName.Web.Customer - 顧客 mvc サイト
  • ProjectName.Web.Admin - 管理 mvc サイト

私の質問：

以下のような静的な「ヘルパー」クラスをどこに配置すればよいでしょうか。

  • 剃刀パーサー
  • シリアライザー/デシリアライザー
  • メール送信者

それらをサービスと呼んで非静的サービスと一緒に配置するのは間違っていると感じます。他の開発者にとっては直感的ではありません...

4

3 に答える 3

1

あなたの質問で与えられた構造で気づいたいくつかのあいまいさに対処したいと思います。あなたの構造を見ると、ある種のオニオン-/クリーン-/ヘキサゴンアーキテクチャを実装しようとしていると思います。

上記の提案されたアーキテクチャ ガイドラインを分析すると、Core プロジェクトには、この場合の Entity Framework などのインフラストラクチャの問題を含むべきではないことが一目で明らかになります。コア自体には、ビジネス/ドメイン モデル (ビジネス ルールに従って) とドメイン サービスのみを含める必要があります。

ここで少し考えてみましょう: EF やその他のインフラストラクチャに関する問題を取り上げるとしたら、Core のテストはどのようになるでしょうか? コアをテストすることにより、通常、一度に1 つのことをテストしようとします...そのため、残りの依存関係をモックアウトする必要はありません。

あなたの質問に正確に答えるために、物事に名前を付けるのは簡単ではありません. 回答では、アプリケーションの残りの部分から物事を分離することをお勧めしているようです。それ自体は良いことですが、お勧めしません。いくつかの優れたプラクティスのためだけに多くのプロジェクトを使用すると、苦痛になる可能性があります。私がこれを書いている理由の例は、3 つの異なることのために 3 つの追加プロジェクトでソリューションをコンパイルするための余分な時間を考えただけです。

これらのインフラストラクチャの問題を整理するための私の提案は次のとおりです。

  1. というプロジェクトを作成します。ProjectName.Infrastructure

    • 必要な NuGet パッケージ/DLL 参照をそれぞれプロジェクトに追加します。
    • このプロジェクト内にディレクトリを作成して、サービスを整理します

  2. 作成したディレクトリごとに、ここにサービスの実装を追加/作成します

    • 各サービスが、消費者クラスに挿入されるインターフェースを実装していることを確認してください
    • 良いアドバイスとして、クラス名に従ってこれらのサービスを名前空間で分けることをお勧めします。ProjectName.Infrastructure.EmailService

  3. 最後の部分は、NInject を介してこれらのインフラストラクチャの問題を結び付けることです。

最後に: あなたが書いたように、これらのサービスをクラス レベルで静的にする必要が本当にないことを願っています。その場合でも、適切な NInject バインディング スコープを介してそのようにバインドできます。

于 2016-06-14T11:33:34.377 に答える
0

これらの無関係な問題をひとまとめにするのではなく、もっと細かくしてみませんか? このような：

  • ProjectName.Infrastructure.Serialization
  • プロジェクト名.インフラストラクチャ.Razor
  • プロジェクト名.インフラストラクチャ.電子メール

このようにして、セマンティクスと構造が改善され、機能を分離したままにできます。

于 2016-06-13T11:43:03.470 に答える
-1

独自のフォルダーまたはコア内のサービス。

静的ヘルパーのためだけに別のプロジェクトを追加することはありません。

于 2016-06-13T11:25:23.303 に答える