如何找出哪个程序集处理了请求

发布于 2024-11-17 21:31:56 字数 705 浏览 4 评论 0原文

我有一个 Web 解决方案，其中包含两个项目（A 和 B），其中 B 引用 A。

在 A 中，我有一个 Html 扩展方法，显然可以从 A 或 B 调用。

我的问题是，一旦调用该方法（通常从部分视图），方法内部是否有一种方法可以确定调用是来自程序集 A 还是程序集 B，而无需传递任何东西给它？

我尝试查看是否可以使用 HttpContext.Current.Request 做任何事情，但找不到任何有用的东西。我可以获取 URI，但仍然无法告诉我发起请求的文件位于哪个程序集。

感谢您的回答 - 该方法返回一个字符串，该字符串来自 string.resx 文件，每个程序集都有一个该文件。这就是为什么我需要知道要访问哪个文件才能返回字符串。由于每个程序集在启动时都会“注册”自身，如果我添加新程序集，我的方法不会改变，因为它只会查找程序集。事实上，我的整个项目不会改变。我此时不引入另一个参数的原因是 b/c 这将意味着大量的更改，而且老实说我没有看到任何好处。虽然我明白你的观点并且我总体上同意它，但我认为在我的情况下，并不是该方法返回不同的东西，它只是根据程序集获取正确的资源文件。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

最偏执的依靠 2024-11-24 21:31:56

正如 SLAks 指出的，您可以检查HttpContext.Current.Application.GetType().Assembly。

不过，我同意约翰的评论，如果您需要这个，您可能做出了错误的设计决策。

问题

你的方法是伪君子。
它对不同的调用者有不同的说法，但不会公开告诉它。

您会看到，每个方法都定义了带有参数和返回类型的特定约定。
例如，int.Parse 表示它接受一个 string 并将其转换为 int。如果我们想更改默认行为，我们还可以为其指定 NumberStyles 和/或 IFormatProvider。

我们消费者不知道 int.Parse 是如何实现的。因为它是静态，所以我们肯定希望它没有副作用，并且对于同一组参数始终返回相同的值。

跟着我重复这个咒语：

显式优于隐式。

如果您发现 int.Parse 以某种方式分析您的代码并根据调用位置更改其行为，您可能会非常生气。

定义上下文是调用者的责任，而不是被调用者的责任。

尝试对以下问题给出简单明了的答案：

如果从程序集 C 调用该方法会发生什么情况？
您将如何对其进行单元测试？如果其他开发人员在单元测试中使用此方法怎么办？
如果重命名程序集 A 或 B 会发生什么？合并他们？进一步分裂他们？
如果发生上述情况，您会记得更改此方法吗？

如果回答上述任何问题显然对您构成挑战，则表明您做错了™。

相反，您应该...

引入参数

考虑方法契约。你可以做些什么来使其完整且具有描述性？

在一个单独的程序集中定义一个通用（如英语）方法，该方法对调用者一无所知，并且具有附加参数，并在具体程序集中为其定义参数填充快捷方式。< /p>

最好这些参数也不知道有关程序集的任何信息。

例如，如果您需要解析方法内的 URL，则可以接受 string baseUrl 或 FuncurlResolver 因此它可以从任何关心指定这些的程序集中使用。

在最坏的情况下，您可以定义一个具有可能的调用者上下文的枚举并将其传递给该方法。这将使您的设计问题变得明确，而不是隐含。明显的问题总是比隐藏的问题好，尽管比没有问题更糟糕。

As SLaks pointed out, you can check HttpContext.Current.Application.GetType().Assembly.

However I agree with John in the comments that you have probably made a bad design decision if you need this.

The Problem

Your method is a hypocrite.
It talks different to different callers but doesn't tell it in open.

You see, each method defines a certain contract with arguments and a return type.
For example, int.Parse says that it takes a string and turns it into an int. If we want to change default behavior, we may also give it NumberStyles and/or IFormatProvider.

We the consumers don't know how int.Parse is implemented. Because it is static, we most certainly expect it doesn't have side effects and will always return the same value for the same set of parameters.

Repeat this mantra after me:

Explicit is better than implicit.

You would probably be very angry if you found out int.Parse somehow analyzes your code and changes its behavior depending on where it's called from.

It's the caller's responsibility to define the context, not the callee's.

Try to give simple and concise answers to questions below:

What happens if the method is called from assembly C?
How would you unit-test it? What if some other developer uses this method in unit tests?
What happens if you rename assembly A or B? Merge them? Split them further?
Will you remember to change this method if anything above happens?

If answering any of the questions above clearly poses a challenge for you, it is a sign you're Doing It Wrong™.

Instead you should...

Introduce a Parameter

Think about the method contract. What can you do to make it full and descriptive?

Define a generic (as in English) method in a separate assembly that doesn't know anything about the callers and has additional parameters, and define parameter-filling shortcuts for it in concrete assemblies.

It's better that these parameters don't know anything about the assemblies either.

For example, if you needed to resolve URLs inside your method, you could accept string baseUrl or Func<string, string> urlResolver so it's potentially usable from any assembly that cares to specify those.

In the worst case, you could define an enum with possible caller contexts and pass it to the method. This will make your design problem explicit, rather than implicit. Obvious problem is always better than hidden problem, although worse than no problem at all.

回复收藏 0 原文