使い方
- インストールコマンドをコピーし、自分の環境へ導入する前にソースを確認します。
- 必要なツール、認証情報、対応環境を原文で確認します。
- 入力と成果物を指定し、出力を資料と照合します。
npx skills add https://github.com/haxen/skills-test --skill keyed-service開始前の確認
- 導入にはモデル契約、API枠、ファイルへのアクセス許可は含まれません。
- スター数や導入数は活動の指標であり、独立した品質・安全性試験ではありません。
リポジトリの原文
見出し、例、コード、表、リンク、参照画像を含む原文を表示しています。
modul-connect/naming-conventions/keyed-service
C# Keyed Service Naming Convention
Rule Definition
When generating or refactoring C# constructors using the [FromKeyedServices] attribute, the parameter name must be derived from the Key Argument rather than the Interface Type.
Logic & Transformation
- Source of Truth: Use the value inside
[FromKeyedServices(...)](e.g.,ModulConnect.Queries.Postgres.Backoffice). - Identifier Extraction: Take the last segment of the Key (e.g.,
Backoffice). - Contextual Suffixing: - If the namespace contains
.Queries., appendQuery.
- If the namespace contains
.Commands., appendCommand.
- Casing: Convert the result to
camelCasefor the parameter and_camelCasefor the private field.
Examples
✅ Correct (Key-Derived)
csharp
public class OrderProcessor(
[FromKeyedServices(ModulConnect.Queries.Postgres.Backoffice)]
IDataAccess backofficeQuery)
{
private readonly IDataAccess _backofficeQuery = backofficeQuery;
}❌ Incorrect (Type-Derived)
csharp
// DO NOT use the interface name "dataAccess"
public class OrderProcessor(
[FromKeyedServices(ModulConnect.Queries.Postgres.Backoffice)]
IDataAccess dataAccess)
{
/* ... */
}Rationale
In a modular architecture, the interface (e.g., IDataAccess) defines the contract, but the Key defines the instance's specific responsibility. Naming the parameter after the Key prevents naming collisions when multiple implementations of the same interface are injected and provides immediate semantic clarity.
