界面最佳实践

Question

我正在研究一个按以下方式拆分的应用程序(简化了一下)

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.我可以看到优势....实际上也许我不能......似乎我们将在框架中拥有数百个接口,我们可能只依赖于'数据',特别是如果这些程序集我将住在同一个锡上

干杯

Answer 1

答案1

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

答案2

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