サービス層とヘルパーオブジェクト?

Question

具体的な事例についてご意見をいただきたいと思います。これはサービス層とサービス層についてです。ヘルパー オブジェクト - 私は理想主義的なパターンを探しているのではなく、単に私の親愛なるプログラミング同僚がこれについてどう考えているかをよく理解しているだけです。

現在のアプリケーションには、完全なドメイン モデル (Linq to Sql、非常に軽量なリポジトリ、IQueryable<> 全体で拡張メソッドを使用して、ビジネス要件に基づいてフィルター/並べ替え/並べ替えを行う) と、グループ化に基づいたサービスを含むサービス層があります。 IRegistrationService などの責任 (ユーザーの登録、ログイン名の利用可能性の確認など)

さて、注意点です。また、暗号化などを行う「ヘルパー」クラスもいくつかあり、そのディレクトリにはグループ化できない他の要素 (カスタム列挙型など) も詰め込んでいます。

ここで、アプリケーションのカスタム リンクの生成を処理する新しいクラスを作成する必要があります。これは、さまざまなオブジェクトを使用し、そのプロパティを考慮した String.Format にすぎません。内部の仕組みは関係ありません。ただし、それを実行するある種の「LinkService」をインスタンス化するのに苦労しています。完了すると、100 個のサービス (およびそのインターフェイス + 実装) ができてしまうような気がします。

同時に、「Helpers」名前空間/ディレクトリ（例:リンクマネージャー）。

何をするか？ビジネス層レベルの要素をどこに置きますか?同時に、ビジネス/サービス層の項目数をどのように制限しますか?セッション アクセスを簡素化して管理する中間オブジェクトなどの小さなヘルパー クラスをどこに貼り付けるのでしょうか (これを厳密に型指定したいと考えていると思いますが、少なくとも私はそうします)。

どう考えているか教えてください？ありがとう ！

Answer 1

私にとって、仕事に適したツールを使用することが重要です。リンクを生成するための何らかの機能 (基本的にはエンティティのプロパティを書式設定された文字列にマッピングすること) が必要な場合は、それを行うための機能を作成します。サービスである必要はありません...逆に、そのようなものに本格的なサービスを提供するのはやりすぎかもしれません。ただし、これを一般的な「ヘルパー」と一括りにするつもりはありません。これには特定の目的と意図があり、その背後に特定の種類の動作があるように思えます。したがって、それが新しいプロジェクトであっても、その動作に適切に適した場所に配置してください。

私は、アプリケーションに「一般的な」コードの巨大な塊を入れないようにしています。すべてには目的があり、特定の動作が実装されます。場合によっては、その目的や動作は高度に再利用可能ですが、それでも私はドメインの再利用可能な要素を論理的に整理しようと努めています。大まかに見ると、ほとんどのアプリケーションは次のように分類されます。

1. クライアント
2. API/サービス
3. ドメイン
4. データアクセス (オプション)
5. フレームワーク

この種の再利用可能な機能の多くは、フレームワークとドメインの間の一種の領域に分類されます。その一部は、フレームワーク内のいくつかの基本クラスおよび/またはインターフェイスおよびサポート型として存在し、残りの半分である具体的な実装はドメイン内に存在します。奇妙に思えることもありますが、この方法で整理すると、ドメインをできる限りクリーンに保つことができ (ビジネス上の懸念に特化)、共通で再利用可能な概念を下位レベルの「フレームワーク」タイプに抽象化することができます。