如何找出哪些组件处理请求 [英] How to find out which assembly handled the request

问题描述

我有一个包含两个项目一个Web解决方案（ A 和乙）是乙引用的 A 。

I have a Web solution which contains two projects (A and B) with B referencing A.

在 A 我有一个 HTML 扩展方法显然可以从或者叫做 A 或乙

In A I have an Html extension method that obviously can be called from either A or B.

我的问题是，一旦该方法被调用（通常是从一个局部视图）是否有方法内的方式来弄清楚该呼叫是否从大会传来的 A 或大会的乙没有通过什么呢？

My question is once the method is called (usually from a partial view) is there a way inside the method to figure out whether the call came from Assembly A or Assembly B without passing anything to it?

我想看看我能做些 HttpContext.Current.Request 什么也没有找到什么有用的东西。我可以得到的URI，但仍然没有告诉我哪大会，发起请求的文件在

I tried to see if I can do anything with HttpContext.Current.Request but could not find anything useful. I can get the URI but that still does not tell me which assembly the file that originated the Request is in.

谢谢您的回答 - 该方法返回一个字符串，该字符串是从我有一个对每个组件的string.resx文件。这就是为什么我需要知道的访问返回字符串的文件。由于每个组装寄存器本身在启动时，如果我添加一个新的组装我的方法不会改变，因为它只会查找assembly.In其实我的整个项目将不会改变。为什么我不能在这个时候引入另一个参数的原因是B / C就意味着变动的数额巨大，我真的看不到好处。虽然我明白你的意思，我一般是同意我想在我的情况下，这不是该方法返回不同的东西，它只是抓住基础上，装配正确的资源文件。

Thanks for your answers - the method returns a string and the string is from a string.resx file which I have one for each assembly. That is why I need to know which file to access to return the string. Since each assembly "registers" itself on start up if I add a new assembly my method will not change, since it will just look up the assembly.In fact my whole project will not change. The reason why I am not introducing another parameter at this time is b/c it will mean a HUGE amount of changes and I honestly don't see the benefit. While I see your point and I generally agree with it I think in my case it's not that the method returns different things , it's just grabbing the correct resource file based on the assembly.

推荐答案

作为SLaks <一个href=\"http://stackoverflow.com/questions/6551954/how-to-find-the-source-of-a-request/6551964#6551964\">pointed出，您可以检查 HttpContext.Current.Application.GetType（）。大会。

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.

您的方法是一个伪君子。结果
  它谈论不同的不同的来电者，但在开放并没有告诉它。

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

您看到的，每个方法定义参数和返回类型有一定的合同。结果
例如， int.Parse 表示，它需要一个字符串键，把它变成一个 INT 。如果我们想改变默认的行为，我们也可以给它的NumberStyles 和/或的IFormatProvider 。

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.

我们的消费者不知道如何 int.Parse 实施。因为它是静态，我们肯定希望它不会有副作用和将始终为同一组参数返回相同的值。

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.

在我重复此口头禅：

明确优于隐式。

您可能会很生气，如果你发现了 int.Parse 莫名其妙地分析您的code和具体情况取决于它是从所谓的改变其行为。

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.

这是调用者的责任来确定的背景下，没有被叫方的。

尽量给简单和简洁的回答以下问题：

Try to give simple and concise answers to questions below:

• 如果该方法是从体C叫会发生什么？


• 你会如何单元测试吗？如果其他一些开发人员使用单元测试这种方法吗？


• 如果您重命名装配A或B，会发生什么？合并吗？进一步细分呢？


• 你会记得要改变这种方法，如果上面有什么事情发生？

• 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...

想想方法的合同。你能做些什么，使之充分和描述？

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.

例如，如果您需要解决你的方法里面的网址，您可以接受字符串的baseUrl 或 Func键＆LT;字符串，字符串＆GT; urlResolver 所以它的潜在可用的的任何的组装，关心指定这些。

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.

这篇关于如何找出哪些组件处理请求的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！