1

我试图改进我的代码结构,所以也许我可以就以下几点和有关如何处理主要服务的问题获得一些输入。

  1. 服务不应该依赖于表示层,因此通过构造函数将诸如 httpcontext 之类的东西传递给服务/服务函数是一种不好的做法,对吗?

  2. 不应该让服务相互引用吗?他们应该只像存储库依赖那样“向下”工作吗?还是认为可以?

  3. 服务是否只包含与过滤和处理来自数据库/存储库的信息直接相关的功能,或者是否可以考虑例如一个专门用于加密和生成随机字符串/密码的类或一个依赖方功能的类处理提供程序?或者他们/一个可能会被认为是实用程序类?

  4. 是否有一种良好且可接受的方式来操作服务内的会话,或者应该将其传递给控制器​​并在那里处理?

4

1 回答 1

1

服务不应该依赖于表示层,因此通过构造函数将诸如 httpcontext 之类的东西传递到服务/服务函数中是一种不好的做法,正确

如果可以避免,请避免。但这取决于,如果它是表示层的服务,那么它就可以了。

不应该让服务相互引用吗?他们应该只像存储库依赖那样“向下”工作吗?还是认为可以?

如果可以避免,请避免。这取决于你的架构,例如,如果你在 asp.net mvc 中工作,你会很好地避免这种情况,并保持在控制器级别编排多个服务的代码类型

服务是否只包含与过滤和处理来自数据库/存储库的信息直接相关的功能,或者是否可以考虑例如一个专门用于加密和生成随机字符串/密码的类或一个依赖方功能的类处理提供程序?或者他们/一个可能会被认为是实用程序类?

您可以使用服务来过滤和处理来自数据库/存储库的信息,也可以创建一个专门用于加密和生成随机字符串/密码的服务。服务是类,因此遵循单一职责原则很重要

是否有一种良好且可接受的方式来操作服务内的会话,或者应该将其传递给控制器​​并在那里处理?

如果您的服务是无状态的,则更好地进行扩展,但是如果您将不得不处理会话或其他生命周期的东西,并且您正在使用 .net 构建 Web 系统,那么您可以做的最好的事情就是使用 asp.net mvc,与Unity集成,以便您获得控制反转,这样您就可以使用生命周期管理器处理会话

于 2012-07-28T03:31:39.933 回答