我和我的团队正在讨论是否使用DTO模型作为接口合同的方法参数。请记住，我们正在使用一个接口，因此我们可以使用依赖性反转并模拟该接口作为单位测试的依赖性。
public interface IContract {
object Method1(DTOModel model);
}
public class Implementation1 {
public object Method1(DTOModel model) {
//do stuff with Property1 and Property2
}
}
public class Implementation2 {
public object Method1(DTOModel model) {
//do stuff with Property3 and Property4
}
}
public class DTOModel {
public string Property1 {get;set;}
public string Property2 {get;set;}
public string Property3 {get;set;}
public string Property4 {get;set;}
}
场景是这样的：我们试图在实现中保持灵活性，以便我们可以同时使用它们。我不同意这种方法，除非两个实施都需要合同中相同的信息。我认为，这将是单独的合同/实施，或者当前合同必须更改，并且只能同时使用1个实施。
我的想法是，如果您以这种方式使用DTO，您将通过允许两个不同的实现方式来击败合同，以不同的方式行事。这也意味着消费者必须知道哪些实现被用来知道完成操作需要哪些属性。最后，这意味着两个实现都可以访问它们不需要的属性。
我解决的方法是将DTOModel的属性传递给实现，并使Implementation2遵守该合同：
public object Method1(string property1, string property2) {
//do stuff with property1 and property2
}
问题是：通过上述DTO进入DTO是可以接受的，因为您知道您的实施不依赖整个合同和/或依靠合同的不同部分来做不同的事情？还是应明确执行其工作需要明确合同？
预先感谢。
更新：为了澄清，这两个实现都具有相同的目的，但在不同的提供商上运行。例如，我们可能使用2个会员提供者，一个提供商需要2个特定属性，另一个提供者需要2个不同的属性。它们的目的是相同的，因为他们都将对用户进行身份验证，但是每个实施方式都不同。
就个人而言，我同意您的分析。我将通过DTO的属性。我不确定通过DTO是否违反了特定的本金或模式 - 可能是，它有一些代码气味，但我的问题是，它是模棱两可的，目的对于实施该公司的人来说尚不清楚将来收入。
假设有人来实施实施3，他们得到了DTO。他们拥有所有这些属性，他们不确定什么有用，什么无用。此外，随着需求的增长和变化，DTO肯定会增长和变化。在不知不觉中，DTO没有4个属性。也许它具有8或10个属性，因为每个人建立实现的参数要求可能略有不同。您可能最终会在某人实施合同并将对象作为具有8个无用属性的参数中传递的时刻。
我将通过明确有用的特定属性，这些属性对给定的实现方法或创建多个DTO，并传递给任何相关的特定属性。在这种情况下，DTO本身的合同可能是一种选择。如果每种方法的要求不同，请创建单独的方法。
如果方法只需要几个参数，请直接将它们作为参数传递。如果它需要三到四个以上的论点，则将其重构以使用DTO可能不是一个坏主意。
但是，如果您走这条路线，请创建特定于这些操作的DTO类（不要在整个地方共享一个庞大的，混乱的类）。如果您的实现从根本上有所不同，以至于它们无法共享相同的输入参数，我将返回绘图板并查看他们是否应该共享相同的接口。另外，重要的是，不要将您在任何其他层（传输，UI等）中使用的DTO传递 - 导致不应该存在的讨厌耦合。
hm，我认为这种方法将打破Liskov原则。
替代性是面向对象的编程中的原理，该原理指出，在计算机程序中，如果s是t的子类型，则可以用类型S的对象替换T型的对象（即类型T类型的对象用亚型的任何对象代替，而不会更改t的任何理想属性（正确性，任务执行等）。
在您的示例中，如果您使用Implementation2更改Implementation1，则该原理将不再满足。