2

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

这让我感到不安，因为我认为服务不应该真的知道哪个客户正在调用它。有人告诉我，这样做比通过方法调用动态传递大量选项更容易。

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

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

你会怎么做？

4

4 回答 4

3

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

所以你的 GUI/App 层应该依赖于业务逻辑层，业务逻辑层应该依赖于数据访问层，等等。

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

我们在谈论什么样的差异，这取决于应用程序的类型？如果您详细说明此处的差异，也许有人可以就解决此问题的其他方法提出一些有用的建议。

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

于 2008-12-03T12:59:02.210 回答
1

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

于 2008-12-03T13:56:57.227 回答
0

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

在 .net 中，设计并没有这种感觉，因为凭据存在于线程上（即，当您设置 IIPrincipal 时，该信息在线程上——它与每个方法调用一起进行通信，但不作为参数进行通信。）

也许您正在寻找更优雅的设计是 ApplicationIdentity 属性。您必须编写一个自定义的，我现在不知道框架中有一个。

于 2008-12-03T13:29:47.313 回答
0

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

你有这种感觉是对的。发送客户端类型以更改行为是不正确的。记录日志不是一个坏主意……但仅此而已。

这是我要做的：

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

想想代码中的函数之类的请求。您不会放置一个改变函数行为的魔术参数。您将创建多个函数，每个函数的行为都不同。使用该函数的人决定调用哪个函数。

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

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

于 2012-06-07T03:33:20.440 回答