在 ASP.Net Boilerplate 中从应用程序服务层调用 SignalR 集线器是一种不好的做法吗?

问题描述

我正在使用带有 ASP.Net Core 2.1 的 Asp.Net 样板模板.
我在 Web.Core 程序集中实现了一个 Hub 并创建了一个控制器.
我可以使用集线器从任何客户端订阅/通知数据，这不是我的问题.

I'm using the Asp.Net boilerplate template with ASP.Net Core 2.1.
I implemented a Hub in the Web.Core assembly and created a controller.
I can subcribe/notify data with my hub from any client, this is not my problem.

我想在应用服务层使用这个集线器，但默认情况下应用服务层不引用 SignalR.

I'd like to use this Hub in the Application Services layer, but SignalR is not referenced by Application Services layer by default.

所以我的问题是:
在应用服务层引用 SignalR 是一种不好的做法吗?

So my question is :
Is it a bad practice to reference SignalR in the the Application Services layer ?

提前致谢！

问候，皮埃尔-吕克

推荐答案

直接依赖 Web 功能在应用层不是一个好的做法.因为，它假定表示层独立.

Directly depending a web feature is not a good practice in the application layer. Because, it is assumed presentation layer independent.

我认为你有几个选择；

1. 如果你认为你永远不会改变 SignalR 并且你永远不会使用另一个应用程序的应用程序层，那么你可以直接引用 SignalR 并使用它.但是，这应该是最坏的情况.
2. 在应用层抽象SignalR通信(定义一个接口)并在web层实现.在这种情况下，最好在应用层定义一个 Null 实现(如果不知道，请搜索空对象模式")以消除依赖并允许应用层在没有 SignalR 的情况下可用.
3. 如果您的应用程序层无法使用 null 实现(也许它需要来自客户端的真正答案)，那么您应该考虑将依赖 SignalR 的代码移至 Web 层.

所以，就像任何好的答案一样，这取决于:)

So, as like any good answer, it depends :)

这篇关于在 ASP.Net Boilerplate 中从应用程序服务层调用 SignalR 集线器是一种不好的做法吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！