コード構造を改善しようとしているので、主にサービスを処理する方法に関する次の点と質問について入力を得ることができるかもしれません。
サービスはプレゼンテーション層に依存してはならないので、 httpcontext のようなものをコンストラクターなどを介してサービス/サービス関数に渡すことは悪い習慣ですよね?
相互に参照するサービスを持つべきではありませんか? たとえば、リポジトリの依存関係のように、「下向き」にのみ機能する必要がありますか? それとも大丈夫と考えられますか？
サービスには、データベース/リポジトリからの情報のフィルタリングと処理に直接関連する機能のみが含まれますか?それとも、たとえば、純粋に暗号化とランダム文字列/パスワードの生成専用のクラス、またはプロバイダーの依存者機能を処理するクラスもサービスと見なすことができますか? それとも、おそらくユーティリティクラスと見なされるのでしょうか?
サービス内でセッションを操作するための適切で受け入れられている方法はありますか、またはこれをコントローラーに渡してそこで処理する必要がありますか?
サービスはプレゼンテーション層に依存すべきではないため、httpcontext のようなものをコンストラクターなどを介してサービス/サービス関数に渡すことは悪い習慣です。
避けられるなら避けましょう。ただし、それがプレゼンテーション層のサービスである場合は、問題ありません。
相互に参照するサービスを持つべきではありませんか? たとえば、リポジトリの依存関係のように、「下向き」にのみ機能する必要がありますか? それとも大丈夫と考えられますか？
避けられるなら避けましょう。アーキテクチャによって異なります。たとえば、asp.net mvc で作業している場合は、これを回避し、複数のサービスを調整するコードの種類をコントローラーレベルで維持することをお勧めします。
サービスには、データベース/リポジトリからの情報のフィルタリングと処理に直接関連する機能のみが含まれますか?それとも、たとえば、純粋に暗号化とランダム文字列/パスワードの生成専用のクラス、またはプロバイダーの依存者機能を処理するクラスもサービスと見なすことができますか? それとも、おそらくユーティリティクラスと見なされるのでしょうか?
データベース/リポジトリからの情報をフィルタリングおよび処理するためのサービスを使用するか、純粋に暗号化とランダムな文字列/パスワードの生成専用のサービスを作成することもできます. サービスはクラスであるため、単一責任の原則に従うことが重要です。
サービス内でセッションを操作するための適切で受け入れられている方法はありますか、またはこれをコントローラーに渡してそこで処理する必要がありますか?
サービスがステートレスである場合はスケーリングに適していますが、セッションやその他のライフサイクルに対処する必要があり、.net で Web システムを構築している場合は、asp.net mvc を使用するのが最善です。Unityと統合されているため、Inversion Of Controlを取得できます。これにより、ライフ タイム マネージャーを使用してセッションを処理できます。