c# - 設定より規約-これは適切なシナリオですか？

Question

オブジェクト指向の方法でフラットな結果を表すResultクラスがいくつかあります。フラットな結果はテキストストリームとして受信され、フォーマッタはフラットな結果を結果のプロパティにフォーマットします。

私の慣習は一貫して<ResultName>フォーマッターになると思います。これは設定より規約の良い例ですか？もしそうなら、Prismではどのようになりますか（Prismがこの質問に重要である場合）。

ありがとう。

Answer 1

Result-Formatter のペアが Prism 固有のものでない限り、Prism がこれに適合する場所はわかりません。

それを超えて、これは構成よりも規則の良いケースだと思います。マッピングまたは構成クラス/ファイルに追加することなく、任意の数の結果タイプとフォーマッターを作成できるためです。

ただし、この規則と API の作成者として、規則を実装してサポートする責任はあなたにあります。結果を処理できるフォーマッターを反射的に発見すると仮定すると、これは最初の要求またはアプリケーションの開始時に行われますか? マッピングをどのようにキャッシュしますか?

構成よりも規約を重視することの大部分は、合理的なデフォルトと彼らが従うことができる標準を支持して、エンド開発者の肩から意思決定を奪うことですが、それは決定があなたとオーバーライドの粒度のレベルに委ねられることを意味します提供するものを決定する必要があります。たとえば、この API のコンシューマは、複数のアセンブリで定義されたフォーマッタを持つことができますか (これは Prism 関連の考慮事項である可能性があります)? もしそうなら、それらのアセンブリはどのように指定されていますか? コンシューマーは慣習から逸脱して、異なる名前のフォーマッターを結果の型にマップできますか?

これはあなただけが使用する API のように聞こえますが、これの多くは意味がありませんが、これらは一般的に適用されるいくつかの考慮事項にすぎません。

Answer 2

いいえ、これは一貫した命名のように見えます。これは、物事を簡単に見つけることができる「発見可能な API」を持つためにも重要です。

構成よりも規則は、アプリケーションの一部が特定の規則に従っている場合に期待どおりに接続/動作する場所です。たとえば、Rails は、Model、View、および Controller が特定のフォルダーに特定の名前であると想定しています。この規則に従っている限り、フレームワークはそれらを自動的に見つけて結び付けます。それは、常に「従わなければならない」という意味ではありません。デフォルトの動作をオーバーライドするオプションもありますが、構成/マッピング ファイルに何かを追加したり、どこかにコードを記述したりする必要があります。

構成よりも慣習は、80% のシナリオを単純かつ迅速に保つのに役立ちます。