5

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

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

在 App 内部，我们正在设置 DI 容器并注册在需要特定接口时将使用哪些具体实现。

即 Data 命名空间中的 IUserRepository 将由 Data.Couchbase 命名空间中的 CouchbaseUserRepository 完成。将来，如果我们用另一种技术（比如 Mongo）替换持久层，我们可以更新 DI 注册，它会通过 MongoUserRepository 来实现

一切都很好……

问题 1

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

问题2

同样，是否值得在框架中拥有一堆接口，其唯一目的是代理数据中的接口，因此应用程序可以仅依赖于框架，而不必依赖于数据。我可以看到优势......实际上也许我不能......看起来我们将在框架中拥有数百个接口，因此我们可以依赖“数据”，特别是如果这些程序集将生活在同一个罐头上

干杯

4

2 回答 2

1

答案 1

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

答案 2

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

于 2013-03-01T15:59:57.557 回答
1

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

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

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

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

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

于 2013-03-01T16:05:43.617 回答