c# - 为什么我们需要C#中的UI，业务和数据访问之间的接口(interface)

Question

我在很多地方看到c＃程序员使用3轮胎架构时，他们倾向于在每一层之间使用接口。例如，如果解决方案是

SampleUI
Sample.Business.Interface
Sample.Business
Sample.DataAccess.Interface
Sample.DataAccess

在这里，UI通过界面调用业务层，业务以相同的方式调用数据访问。
如果这种方法是为了减少各层之间的依赖关系，则它已经在类库中使用，而无需额外使用接口。
下面的代码示例

样品业务

public class SampleBusiness{
   ISampleDataAccess dataAccess = Factory.GetInstance<SampleDataAccess>();
   dataAccess.GetSampledata();
}

Sample.DataAccess.Interface

public interface IsampleDataAccess{
   string GetSampleData();
}

Sample.DataAccess

public class SampleDataAccess:ISampleDataAccess{
  public string GetSampleData(){
     returns data;// data from database
  }
}

两者之间的推论有什么用吗？
如果我使用newSampleDataAccess（）。SampleData（）并删除完整的接口类库该怎么办？

Answer 1

代码合同

在设计过程中使用接口有一个显着的优势：它是一种合同。

在以下意义上，接口是合同的规范：


如果我使用（使用）该接口，那么我将限制自己使用该接口公开的内容。好吧，除非我想打脏（反射等）。
如果实现该接口，那么我将限制自己提供该接口公开的内容。


用这种方式做事的好处是，它可以简化开发团队中各层之间的工作分配。它允许一层的开发人员提供咳嗽界面咳嗽，下一层可以使用它与之进行通信……甚至在实现此类界面之前。

一旦他们在界面上达成协议。至少在最小可行接口上。他们可以开始并行开发层，知道其他团队将维护合同的一部分。



嘲笑

以这种方式使用接口的副作用是，它允许模拟组件的实现。这简化了单元测试的创建。这样，您可以隔离测试层的实现。因此，您可以轻松地区分某个层由于存在缺陷而发生故障以及何时由于其下面的层存在缺陷而发生故障。

对于由一个人或一个小组进行的项目，这些项目在绘制清晰的线条以分隔工作方面不会太费事，模拟的能力可能是实现接口的主要动机。

例如，考虑一下，如果您想测试表示层是否可以正确处理分页，但是您需要请求数据来填充这些页面。可能是这样的：


下面的图层尚未准备好。
该数据库尚无要提供的数据。
它失败了，他们不知道分页代码是否正确，该缺陷来自代码中更深的一点
等等…


无论哪种方式，解决方案都是嘲笑的。此外，如果您有要模拟的接口，则模拟会更容易。



改变实施

如果出于某种原因，一些开发人员决定要更改其层的实现，则可以信任由接口施加的合同。这样，他们可以交换实现，而不必更改其他层的代码。

什么理由？


也许他们想测试一种新技术。在这种情况下，他们可能会创建替代实现作为实验。此外，他们希望两个版本都可以工作，以便他们可以测试哪个版本更好。

附录：不仅用于测试两个版本，还可以简化回滚到主版本的过程。当然，他们可以通过源代码版本控制来完成此任务。因此，我不会将回滚视为使用界面的动机。但是，对于任何不使用版本控制的人来说，这可能都是一个优势。对于不使用它的任何人...开始使用它！
也许他们需要将代码移植到其他平台或数据库引擎。在这种情况下，他们可能也不想扔掉旧代码……例如，如果他们有运行Windows和SQL Server的客户端以及运行Linux和Oracle的其他客户端，则维护两个版本都是有意义的。


当然，无论哪种情况，您都希望能够通过做最少的工作来实现这些更改。因此，您不想更改上面的层以针对其他实现。取而代之的是，您可能具有某种形式的控制容器的工厂或倒置形式，可以将其配置为对所需的实现进行依赖项注入。



缓解变更传播

当然，他们可能决定更改实际的接口。如果开发层的开发人员需要在接口上添加其他内容，则可以将其添加到接口中（考虑到团队为批准这些更改而设置的任何方法），而不会弄乱另一个团队正在工作的类的代码上。在源代码版本控制中，这将简化边距更改。



最后，使用层体系结构的目的是关注点分离。这意味着需要将变更原因分开……如果您需要更改数据库，则您的更改不应传播到专用于向用户提供信息的代码中。当然，团队可以通过具体的课程来实现这一目标。但是，接口提供了良好而明显的，定义明确的，受语言支持的障碍，阻止了变更的传播。特别是如果团队对责任有良好的规定（不，我不是说代码问题，我是说什么开发人员负责做什么）。