要求消费者实现一个接口只是为了传递参数是不是很糟糕？
只是为了帮助形象化，我的具体情况是一个 ASP.NET C# MVC 网站，其汇编内容如下：
MyWebAssembly.Web
Controllers
MyWebAssembly.Models
PurchaseViewModel : IBillingAddress
SubscribeViewModel : PurchaseViewModel
AddCreditsViewModel : PurchaseViewModel
MyWebAssembly.BLL
IBillingAddress
BeginPurchase(IBillingAddress, etc.)
MyWebAssembly.Data
Models
我有大约 100 个与我的业务逻辑紧密耦合的 ViewModel。我已经将这些提取到接口（如上所示）以避免向自动映射添加另一层相同的模型，现在我终于将我的业务层与网站分离了。
我想这是这个过程中很好的第一步。这使我能够将业务逻辑移出程序集，但我觉得很脏，就像我所做的只是随机播放代码一样。并非我的所有 ViewModel 都是这样耦合的，但 IBillingAddress 只是多个示例之一。
你认为要求消费者实现接口只是为了传递参数是不好的形式吗？当我这样做时，我觉得我回到了 Win32 API 时代。我应该再向我的业务方法传递 10 个标准类型参数吗？我忽略的架构是否有一些明显的支点？
编辑：
我还在考虑这个。也许这个例子让我感到困惑的原因之一是因为 BillingAddress 似乎是一个相对固定的依赖接口。将其公开并将其构建到 ViewModel 中更有意义。我想如果它是一个潜在的移动目标（例如 ICustomer），映射交互会更有意义。仍然需要您的建议。