我正在开发一个按以下方式拆分的应用程序（简化一点）
App
|
Framework
|
Data (Persistance)
|
Data.Couchbase
Inside App我们正在设置DI容器并注册在需要特定接口时将使用哪些具体实现。
即。 Data命名空间中的IUserRepository将由Data.Couchbase命名空间中的CouchbaseUserRepository实现。将来，如果我们用另一种技术换掉持久层，比如Mongo，我们可以更新DI注册，并且可以通过MongoUserRepository来实现
一切顺利......
问题1
提供跨越系统边界的接口，但在 的Data.Couchbase命名空间本身中有明显的好处。如果ICouchbaseUserRepository接口本身不提供任何额外功能，是否有任何意义？好像我们注册了IUserRepository - ＆gt;应该足够好的CouchbaseUserRepository？在具体实现中类似的是将这些组件进一步分解为可能不会被换出的接口有任何意义
问题2
同样值得在Framework中拥有一堆接口，其唯一目的是代理数据中的接口，因此App只能依赖于Framework而不必依赖于Data。我可以看到优势....实际上也许我不能......似乎我们将在框架中拥有数百个接口，我们可能只依赖于'数据'，特别是如果这些程序集将生活在同一个锡上
干杯
答案 0 :(得分：1)
实现IUserRepository的CouchbaseUserRepository非常有意义。您的所有应用程序逻辑仅使用接口，因此，如果您稍后切换到Mongo，则只需使MongoUserRepository实现相同的接口。
如果您正在构建一个大型应用程序，那么肯定要使用两层接口：db level和framework level。如果它不是那么大，那可能太多了。在任何一种情况下，在框架级别创建接口也不是错误的。
答案 1 :(得分：1)
这两个问题都属于编码和设计风格领域。因此，它们可能更适合程序员站点。 （https://softwareengineering.stackexchange.com/）
在处理设计问题时，领先的做法很明确 - 您应该有一个界面来定义您的数据库层，然后您可以轻松地注入新类型的数据访问。
如果没有对界面的功能需求（正如您在问题中所描述的那样），界面的需求就是提供清晰度 - 编码风格使您的系统更加清晰。
例如，在联系人管理系统中，定义到定义联系人的数据库/系统“对象”的接口可能是有意义的。然后另外为人员和组织创建接口。这在本申请的上下文中是有用的。为文档管理系统创建这样的接口是没有意义的。对于它们两者，您需要为DB注入定义的接口。
您作为设计师和程序员已经决定 - 在设计系统时选择样式没有严格的规则。