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

Question

具体的なケースについてご意見をお寄せください。これはサービスレイヤとヘルパーオブジェクトに関するものです。理想的なパターンは探していませんが、私の親愛なるプログラミング仲間がこれについて考えるものをよく理解しているだけです。

私の現在のアプリケーションでは、フルドメインモデルビジネス要件に基づいてフィルタリング/並べ替え/並べ替えを行うために、IQFreeable <の拡張メソッドを使用します）、IRegistrationService（登録ユーザー、checkなど、責任のグループ化に基づいたサービスを含むサービスレイヤーログイン名などの可用性）

警告が表示されます。私はまた、暗号化のようなことをするいくつかの "ヘルパー"クラスを持っていて、私はまた、そのディレクトリ内のその他のグループ化不可能な要素（カスタムenumsなど）を詰め込んできた

私は今処理する新しいクラスを作成する必要があります私のアプリケーション用のカスタムリンクの生成は、異なるオブジェクトを持つString.Format以上のものではなく、そのプロパティを考慮に入れたものです。内部の動作は無関係です。しかし、私は難しい時に "LinkService"をインスタンス化してしまいました。私が終わったら100サービス（そしてそのインターフェース+実装）で終わるような気がします。

同時に、「ヘルパー」名前空間/ディレクトリ（LinkManagerなど）にクラスやその他のものが混在しているような気がしません。

どうすればよいですか？あなたはまだ幾分ビジネス層レベルのものを置いていますが、同時にあなたのビジネス/サービス層のアイテム数をどのように制限しますか？セッションのアクセスを簡素化して管理する中間オブジェクトなどの小さなヘルパークラスはどこに張っていますか（これは強く型付けしたいと思っています - 少なくとも私はします）？

あなたの意見は教えてください。ありがとう！

Answer 1

私にとっては、ジョブに適切なツールを使用することが重要です。基本的に、エンティティプロパティの書式設定された文字列へのマッピングである、リンクを生成するための何らかの種類の機能が必要な場合は、それを行うための機能を記述します。それはサービスである必要はありません...逆に、そのようなもののための完全な吹き飛ばされたサービスを持つことはおそらく過剰です。しかし、私はこれをあなたの一般的な「ヘルパー」に集中させるだけではありません。これは、特定の目的や意図を持ったもので、その背後には特定の種類の動作があるように思えます。そういうわけで、たとえそれが新しいプロジェクトであっても、それはその行動に適切な場所に置いてください。

私のアプリケーションでは、 "一般的な"コードの巨大な塊を持っていないようにしてください。すべてが目的を持っており、特定の動作を実装しています。時にはその目的と振る舞いは再利用性が高いですが、私はまだ論理的に自分のドメインの再利用可能な要素を整理しようとしています。ハイレベルから、私は次のように分かれて、私のアプリケーションのほとんどを参照してください。

1. クライアント
2. API /サービス
3. ドメイン
4. データアクセス（オプション）
5. 枠組み

この種の再利用可能な機能の多くは、フレームワークとドメインの間の一種の領域に該当します。その一部は、フレームワーク内のいくつかの基本クラスおよび/またはインタフェースおよびサポート型として存在し、残りの半分、具体的な実装は、私のドメイン内に存在する。時には奇妙に思えるかもしれませんが、このように整理することで、私のドメインを可能な限りきれいに保つことができます（ビジネス上の懸念に専念しています）が、共通の概念と再利用可能な概念を低レベルの "フレームワーク"