パラメータを渡すためだけにインターフェースを実装するようコンシューマに要求するのは悪いにおいがしますか?
視覚化を容易にするために、私の特定の状況は、次のアセンブリ コンテンツを含む ASP.NET C# MVC Web サイトです。
MyWebAssembly.Web
Controllers
MyWebAssembly.Models
PurchaseViewModel : IBillingAddress
SubscribeViewModel : PurchaseViewModel
AddCreditsViewModel : PurchaseViewModel
MyWebAssembly.BLL
IBillingAddress
BeginPurchase(IBillingAddress, etc.)
MyWebAssembly.Data
Models
ビジネス ロジックと密接に結合された約 100 の ViewModel があります。これらをインターフェイスに抽出して (上記のように)、同じモデルの別のレイヤーを automap に追加しないようにしました。最終的にビジネス レイヤーを Web サイトから分離することになりました。
これは、このプロセスの最初のステップとしては優れていると思います。これにより、ビジネス ロジックをアセンブリの外に移動することができましたが、コードをシャッフルしただけなので、汚いと感じました。すべての ViewModel がこのように結合されているわけではありませんが、IBillingAddress は複数の例の 1 つにすぎません。
パラメータを渡すためだけにインターフェースを実装することを消費者に要求するのは悪い形だと思いますか? そうしていると、Win32 API の時代に戻ったような気がします。ビジネス メソッドにあと 10 個の標準型パラメーターを渡す必要がありますか? 私が見落としている私のアーキテクチャに明らかなピボットはありますか?
編集：
私はまだこれを考えています。おそらく、この例が私を混乱させる理由の 1 つは、BillingAddress が依存する比較的固定されたインターフェイスのように見えるためです。それを公開してViewModelに組み込む方が理にかなっています。それが移動する可能性のあるターゲット (たとえば、ICustomer など) である場合は、マッピングされたインタラクションの方が理にかなっていると思います。あなたのアドバイスはまだ必要です。