接口最佳实践

Question

接口最佳实践

c#oopinterfacedependency-injectiondependencies

5

我正在开发一个应用程序，它按以下方式划分（稍微简化一下）

App
|
Framework
|
Data (Persistance)
|
Data.Couchbase

在App内部，我们正在设置DI容器并注册当需要特定接口时将使用哪些具体实现。例如，在Data命名空间中的IUserRepository将由Data.Couchbase命名空间中的CouchbaseUserRepository来实现。将来，如果我们用另一种技术替换持久化层，比如Mongo，我们可以更新DI注册表，并且它将被MongoUserRepository所实现。

这很好....

问题1

提供跨系统边界的接口显然有好处，但在Data.Couchbase命名空间本身内呢？如果ICouchbaseUserRepository不提供任何额外的功能，那么有必要吗？似乎如果我们注册IUserRepository -> CouchbaseUserRepository就足够了？同样，在具体实现中，是否有必要进一步将这些组件拆分为可能不会被替换的接口？

问题2

同样，在Framework中拥有一堆仅用于代理到Data接口的接口是否值得？因此，App只能依赖于Framework而不必依赖于Data。我可以看到优点...实际上也许我看不到...如果这些程序集将位于同一台机器上，似乎我们将在框架中拥有数百个接口，而我们只需依赖于“Data”尤其是如果这些程序集将位于同一台机器上。

- managedheap84

3

一道问题包含两个问题可能会遇到一些阻力。 - Hogan

为什么？SO上有很多问题都包含2、3、4个或更多的问题。这些问题是相关的，将它们分开并为每个问题重复介绍并不明智。 - managedheap84

2个回答

1

这两个问题属于编码和设计风格领域。因此它们可能更适合Programmers网站。（https://softwareengineering.stackexchange.com/）

在处理设计问题时，领先的做法很明确——您应该拥有一个定义DB层的接口，然后可以轻松地注入新类型的数据访问。

当没有接口的功能需求（就像您在问题描述中所说），接口的需要在于提供清晰性，它是编程风格，使您的系统更加清晰。

例如，在联系人管理系统中，定义一个与数据库/系统“对象”相对应的接口，该对象定义了一个联系人，可能是有意义的。然后，除此之外，还要为人和组织制定接口。这在此应用程序的上下文中是有帮助的。为文档管理系统创建这样的接口是没有意义的。对于这两种情况，都需要为DB注入定义接口。

作为设计师和程序员，您必须决定——在设计系统时，不存在硬性规则，涉及风格选择。

- Hogan

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Timothy Shields · Accepted Answer

答案1

CouchbaseUserRepository实现IUserRepository非常有意义。您的所有应用程序逻辑仅使用接口，因此如果您以后切换到Mongo，则只需使MongoUserRepository实现相同的接口即可。

答案2

如果您正在构建大型应用程序，请确保使用两层接口：数据库层和框架层。如果不是很大，则可能太多了。在任何情况下，在框架级别创建接口也不是错误的。