接口最佳实践[关闭]答案

【问题标题】：Interface best practices [closed]接口最佳实践[关闭]
【发布时间】：2013-02-16 04:18:38
【问题描述】：

我正在开发一个按以下方式拆分的应用程序（有点简化）

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。我可以看到优势......实际上也许我不能......看起来我们将在框架中拥有数百个接口，因此我们可以依赖“数据”，特别是如果这些程序集生活在同一个罐子里

干杯

【问题讨论】：

一个问题中的两个问题可能会遇到一些阻力。
为什么？ SO上有很多问题，其中有2,3,4+个问题。两者都是相关的，这比分成 2 并为每个重复介绍更有意义...

标签： c# oop interface dependency-injection dependencies

【解决方案1】：

回答 1

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

回答 2

如果您正在构建一个大型应用程序，那么一定要使用两层接口：数据库级别和框架级别。如果它不是那么大，它可能太多了。在任何一种情况下，在您的框架级别创建接口都不会是错误的。

【讨论】：

对于答案 1，一个 CouchbaseUserRepository 实现一个 'ICouchbaseUserRepository' 怎么样，它只是一个从 IUserRepository 派生的空接口 - 我觉得这可能有点过头了答案 2：附加值是什么在这种情况下呢？
拥有 ICouchbaseUserRepository 没有任何附加价值。第二部分增加的价值是应用程序在业务逻辑级别运行功能，而不是直接使用数据库。您不希望在您的应用代码中进行直接的数据库交互。
你说得对，直接与数据库交互并不好——这就是为什么数据层只包含 Data.Couchbase 中具体实现的接口。我在问题 2 中得到的是为什么要尝试抽象出框架背后的 Data 命名空间 - 无论哪种方式，您都将从应用程序访问与数据相关的接口......也许答案是 Data 在逻辑上与 Framework 并列而不是通过它访问

【解决方案2】：

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

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

如果对界面没有功能需求（正如您在问题中描述的那样），界面的需要是为了提供清晰性——它是使您的系统更清晰的编码风格。

例如，在联系人管理系统中，为定义联系人的数据库/系统“对象”定义接口可能是有意义的。然后另外为人和组织制作接口。这在此应用程序的上下文中很有帮助。为文档管理系统创建这样的接口是没有意义的。对于它们两者，您都需要为 DB 注入定义的接口。

作为设计师和程序员，您已经决定了——在设计系统的风格选择方面没有硬性规定。

【讨论】：