0

我对在用户界面中注入存储库的趋势似乎有些困惑。

我一直在构建或工作在 UI 完全不了解存储库层但只知道上面的层的系统上。

谷歌搜索了一下，发现一个和我有同样问题的开发人员，请参见下面的链接

https://softwareengineering.stackexchange.com/questions/199799/should-a-repository-be-passed-in-to-the-user-interface

但是，阅读答案我仍然不清楚，对我来说，我们应该将存储库注入 ui 并不好。

如果我有以下情况，

UI(dll1)-->ServiceGateway(dll2)->Service(wcf)(dll3)-->BizLayer(dll3)-->Dal(dll3)

为什么要一直注入存储库？

是的，它很适合模拟，但没有什么能阻止开发人员直接从 UI 调用存储库。它发生了很多次。

有人可以指出一个链接或解释为什么现在曾经很糟糕的事情是“最佳实践”吗？

4

3 回答 3

1

存储库是 UI 和持久性之间的抽象。您可能需要比这更多的抽象级别，或者可能就足够了。这将取决于应用程序。重要的是该抽象层存在，UI 通过该抽象层访问持久性功能，并且该层被注入到 UI 中，而不是通过定位器（反）模式访问。

于 2013-11-05T08:59:27.350 回答
0

您的 WCF 服务应该注入数据源，因为它是一个独立的应用程序，恰好暴露了数据，并以这种方式充当构建在它之上的应用程序的 DAL。

您的网站 (UI) 并不关心您的服务 (DAL) 如何获取其数据。

在您的示例中，只有 UI 在启动时使用ServiceGateway. 它不需要（必须）知道有关服务实现的任何信息，它只是调用服务。

事实上，除非您从您的 UI 自托管 WCF 服务，否则您甚至无法对来自消费应用程序的服务依赖项做任何事情：服务必须在服务启动时注入它们。在这种情况下，自托管也意味着 ASP.NET 网站托管自己的服务。在这种情况下，您还会在 中找到该服务的存储库注入Global.asax，因为它在网站和服务之间共享（我仍然建议不要这样做）。

于 2013-11-05T08:44:29.233 回答
0

对不起，我也不能给你一个明确的答案，但我确实和你一样担心。

在最近的一个项目中，我设置了数据库、dal 和 bll 的一部分，pm 一直在努力将数据隐藏在 UI 中，我完全同意。然后突然间，他坚持要从 UI 注入存储库——因为这使测试更容易。

我想，我和你一样困惑。当我问什么是阻止开发人员直接访问数据时，因为他可以访问存储库，他的回答是“他不应该”。因此，我们构建了一个具有独立层的完整框架，以确保我们控制数据访问，最终只依赖于“让我们希望开发人员表现良好”。

我完全赞成将存储库注入尽可能合理地靠近数据层，并且当然不会将这个责任留给 UI。

于 2013-11-05T09:07:06.463 回答