I noticed that the MapRoute extension includes an overload that accepts a string[] parameter which is called 'namespaces'. I read what Google had for me on it, and supposedly this is to help the framework find controllers in places it wouldn't otherwise look.
我注意到MapRoute扩展包含一个重载，它接受一个名为'namespaces'的string []参数。我读了谷歌对我的看法，据说这是为了帮助框架在其他地方看不到的地方找到控制器。
I did some spiking, and tried putting controllers in weird locations. I put one in the Scripts folder; I even built one in a separate assembly with a separate root namespace.
我做了一些尖峰，并尝试将控制器放在奇怪的位置。我把一个放在Scripts文件夹中;我甚至在一个单独的程序集中构建了一个具有单独的根命名空间
Without putting anyting in the namespaces param, everything worked fine. If I put just one of the namespaces in the namespaces param, it still found all my controllers. I thought maybe it would use that array to disambiguate between similarly named controllers, but that didn't happen either. A HomeController in MyProj.Controllers and one in SomeOtherName.Stuff would collide still.
如果不在命名空间参数中添加任何内容，一切都运行正常。如果我只在命名空间参数中放置一个命名空间，它仍然可以找到我的所有控制器。我想也许它会使用该数组来消除类似命名的控制器之间的歧义，但这也没有发生。 MyProj.Controllers中的HomeController和SomeOtherName.Stuff中的HomeController仍然会发生冲突。
So my question is, is that parameter deprecated? Or is it still used somehow in a way that I have yet to discern?
所以我的问题是，该参数是否已被弃用？或者它仍然以某种方式使用我尚未辨别的方式？
2 个解决方案
#1
5
Ok, so after further testing, I figured out that it is not a filter, exactly, but it kinda is also. I gave you 'answer' credit even though you're partially wrong.
好吧，经过进一步的测试，我发现它不是一个过滤器，确切地说，但它也有点。即使你有部分错误，我也给你“回答”信用。
So, it does, after all, act like I thought it should which is to say it disambiguates. Basically, the logical flow is something like this:
毕竟，它确实表现得像我认为它应该说它消除歧义。基本上，逻辑流程是这样的：
- Look for a namespace in the _cache that matches one in the namespaces array
- if that's found, look for a controller of the right name
- 如果找到了，找一个正确名称的控制器
- -- if that's found, return it
- - 如果找到了，请将其归还
- -- if it's not found, return search everywhere else that it'd normally look
- - 如果找不到，请返回其通常看的其他地方的搜索
- 在_cache中查找与命名空间数组中的命名空间匹配的命名空间（如果已找到），查找正确名称的控制器 - 如果已找到，则返回它 - 如果找不到，则返回搜索其他任何地方通常看
- if it's not found, search everywhere lese
- 如果没有找到，搜索到处都是
So, in short, my thought that the namespaces array would serve to disambiguate was correct. The reason my first test in that regard failed is that it only does a perfect match, and I made the mistake of using just the root n/s from the assembly (in other wordss, MyRoot instead of MyRoot.Controllers).
因此，简而言之，我认为命名空间数组可以消除歧义是正确的。我在这方面的第一次测试失败的原因是它只进行了完美的匹配，我错误地只使用了程序集中的根n / s（换句话说，MyRoot而不是MyRoot.Controllers）。
What this namespaces thing allows, then, is to have a HomeController in two different namespaces and match them differently depending on the url or params.
那么这个名称空间允许的是在两个不同的名称空间中有一个HomeController，并根据url或params不同地匹配它们。
#2
4
No, the value is not deprecated. It is used in DefaultControllerFactory.cs. Note that if the value is supplied, it completely replaces the standard name spaces searched. When the parameter is not supplied, the name spaces searched our determined by:
不，该值不会被弃用。它在DefaultControllerFactory.cs中使用。请注意，如果提供了该值，它将完全替换搜索的标准名称空间。当未提供参数时，搜索的名称空间由以下内容确定：
HashSet<string> nsDefaults = new HashSet<string>(ControllerBuilder.DefaultNamespaces, StringComparer.OrdinalIgnoreCase);
When the parameter is supplied, the list you supply replaces this value.
提供参数后，您提供的列表将替换此值。
In either case, DefaultControllerFactory calls:
在任何一种情况下，DefaultControllerFactory都会调用：
GetControllerTypeWithinNamespaces(controllerName, nsDefaults);
...with the list, either the one you supplied, or the default. So it is clear that the value is supported.
...使用列表，您提供的列表或默认值。很明显，该值是受支持的。
When you look at the source code there, and in ControllerTypeCache, you can see the real purpose of the namespaces value: It does not cause the controller factory to look in places that would not otherwise look; rather it is a filter. In other words, it prevents the default controller factory from looking and name spaces that it would otherwise search for controllers.
当你在那里查看源代码时，在ControllerTypeCache中，你可以看到名称空间值的真正目的：它不会导致控制器工厂查看看不到的地方;相反，它是一个过滤器。换句话说，它会阻止默认控制器工厂查找并命名它本来会搜索控制器的空间。
#1
5
Ok, so after further testing, I figured out that it is not a filter, exactly, but it kinda is also. I gave you 'answer' credit even though you're partially wrong.
好吧，经过进一步的测试，我发现它不是一个过滤器，确切地说，但它也有点。即使你有部分错误，我也给你“回答”信用。
So, it does, after all, act like I thought it should which is to say it disambiguates. Basically, the logical flow is something like this:
毕竟，它确实表现得像我认为它应该说它消除歧义。基本上，逻辑流程是这样的：
- Look for a namespace in the _cache that matches one in the namespaces array
- if that's found, look for a controller of the right name
- 如果找到了，找一个正确名称的控制器
- -- if that's found, return it
- - 如果找到了，请将其归还
- -- if it's not found, return search everywhere else that it'd normally look
- - 如果找不到，请返回其通常看的其他地方的搜索
- 在_cache中查找与命名空间数组中的命名空间匹配的命名空间（如果已找到），查找正确名称的控制器 - 如果已找到，则返回它 - 如果找不到，则返回搜索其他任何地方通常看
- if it's not found, search everywhere lese
- 如果没有找到，搜索到处都是
So, in short, my thought that the namespaces array would serve to disambiguate was correct. The reason my first test in that regard failed is that it only does a perfect match, and I made the mistake of using just the root n/s from the assembly (in other wordss, MyRoot instead of MyRoot.Controllers).
因此，简而言之，我认为命名空间数组可以消除歧义是正确的。我在这方面的第一次测试失败的原因是它只进行了完美的匹配，我错误地只使用了程序集中的根n / s（换句话说，MyRoot而不是MyRoot.Controllers）。
What this namespaces thing allows, then, is to have a HomeController in two different namespaces and match them differently depending on the url or params.
那么这个名称空间允许的是在两个不同的名称空间中有一个HomeController，并根据url或params不同地匹配它们。
#2
4
No, the value is not deprecated. It is used in DefaultControllerFactory.cs. Note that if the value is supplied, it completely replaces the standard name spaces searched. When the parameter is not supplied, the name spaces searched our determined by:
不，该值不会被弃用。它在DefaultControllerFactory.cs中使用。请注意，如果提供了该值，它将完全替换搜索的标准名称空间。当未提供参数时，搜索的名称空间由以下内容确定：
HashSet<string> nsDefaults = new HashSet<string>(ControllerBuilder.DefaultNamespaces, StringComparer.OrdinalIgnoreCase);
When the parameter is supplied, the list you supply replaces this value.
提供参数后，您提供的列表将替换此值。
In either case, DefaultControllerFactory calls:
在任何一种情况下，DefaultControllerFactory都会调用：
GetControllerTypeWithinNamespaces(controllerName, nsDefaults);
...with the list, either the one you supplied, or the default. So it is clear that the value is supported.
...使用列表，您提供的列表或默认值。很明显，该值是受支持的。
When you look at the source code there, and in ControllerTypeCache, you can see the real purpose of the namespaces value: It does not cause the controller factory to look in places that would not otherwise look; rather it is a filter. In other words, it prevents the default controller factory from looking and name spaces that it would otherwise search for controllers.
当你在那里查看源代码时，在ControllerTypeCache中，你可以看到名称空间值的真正目的：它不会导致控制器工厂查看看不到的地方;相反，它是一个过滤器。换句话说，它会阻止默认控制器工厂查找并命名它本来会搜索控制器的空间。