在服务层中切换客户端逻辑是错误的吗？

Question

我们有两个客户端应用程序（一个Web应用程序和一个代理应用程序）访问同一服务上的方法，但需求略有不同。我的团队希望通过将ApplicationType参数传递给每个方法来控制服务端的行为 - 这实际上是一个包含调用客户端应用程序名称的枚举 - 然后将其用作数据库查找的键以配置服务。特定于客户的选项。

关于这一点让我感到不安，因为我不认为该服务应该真正知道哪个客户端正在调用它。我被告知这样做比通过方法调用动态传递一组选项更容易。

客户端应用程序告诉服务他们是谁有什么问题吗？或者传递配置键与一组参数化选项之间没有区别吗？

我可以看到的一个直接问题是，如果我们将服务打开到第三方运行的另一个客户端，我们必须在本地维护它们的配置设置。目前我们拥有两个客户端应用程序，所以这不是一个问题。

你会怎么做？

Answer 1

在分层解决方案中，您应始终将您的图层视为类似洋葱的图层，并且依赖项应始终向内，而不是向外。

因此，您的GUI / App层应该依赖于businesslogic层，businesslogic层应该依赖于数据访问层，类似。

除非您对客户端（web，win，wpf，cli）进行分类，或者将其与客户端配置文件（客户端应用程序可以配置）进行一般化，否则我永远不会传递调用应用程序的名称，因为这会使业务逻辑层意识到并依赖于外层。

我们谈论的是什么样的差异取决于应用的类型？如果你在这里详细说明差异，也许有人可以提出一些有用的建议来解决这个问题。

但在走下你描述的道路之前，我肯定会寻找其他方法。

Answer 2

你不能创建两个不同的服务，每个应用程序一个吗？这两个服务将共享大量代码或调用具有不同参数化的单个内部服务，具体取决于所调用的外部服务。

Answer 3

从设计角度来看，这与拥有不同配置文件的用户没有什么不同。从安全角度来看，我希望您的应用程序正在做一些事情来识别自己，以免一个应用程序的用户找到一种方法来调用其他应用程序逻辑作为黑客。 （图像是黑手党和银行同时使用的人力资源应用程序，一个客户会对在共享应用程序主机上攻击其他客户的应用程序感兴趣）

在.net中，设计不会这样，因为凭证存在于线程上（即当您设置IIPrincipal时，该信息会在线程上运行 - 它与每个方法调用一起传递，但不是作为一个参数。）

对于更优雅的设计，您可能正在寻找的是ApplicationIdentity属性。你必须写一个自定义的，我现在不知道框架中的一个。

Answer 4

如果没有一个可靠的例子，这是一个难以讨论的话题。

你是这样的感觉。在客户端类型中发送以更改行为是不正确的。记录这不是一个坏主意......但这就是它。

以下是我要做的事情：

• 查看每种方法，看看哪些方法有所不同以及原因。
• 为不同的用法创建不同的方法。方法名称应该是自解释的。如果您需要破坏兼容性，您可以获得更多控制权（假设您没有使用版本控制系统，这对于内部服务而言过于苛刻）。
• 在某些情况下，请求参数（标志/枚举值）更合适。
• 在某些情况下，了解操作环境更合适（尤其是数据安全性）。操作环境几乎总是在登录请求期间发送。像“有人值守”/“安全”（代理客户端）与“无人值守”/“不安全”（Web客户端）之类的东西。现在您必须交换会话密钥（HTTP cookie或应用程序级会话ID）。如果你需要100％无状态，会话显然不起作用 - 特别是如果你想在没有会话复制的情况下扩展...如果你有这个要求，在每个请求中发送一个结构。

考虑代码中的函数等请求。你不会放一个改变函数行为的魔术参数。您将创建多个函数，每个函数的行为都不同。无论谁使用该功能，都可以决定调用哪一个。

那么为什么客户类型如此错误呢？客户端类型本身没有特定含义。它有很多含义，它们可能会随着时间而改变。这只是信息，这就是为什么它是一个方便的记录。操作环境确实具有特定含义。

这是一个需要考虑的方案：如果开发的新客户端类型稍有不同会破坏与原始请求的兼容性，该怎么办？现在你有两个请求。 2个客户端使用请求A，1个客户端使用请求B.如果将客户端类型传递给每个请求，则服务器应该适用于每种可能的客户端类型。更难以测试和维护!!