愚蠢的命名空间问题
好的,我有一个名为 BusinessLayer 的 c# 项目,它生成一个名为 BusinessLayer 的程序集,命名空间为 BusinessLayer。
在这个项目中,我使用文件夹来存储代码。其中一个文件夹名为 FilterElements,它包含名为 FilterKeyReversal、FilterRandom 和 FilterToday 的文件夹。
我们以 FilterRandom 文件夹为例。它有一个名为 LessThan10DaysGreaterThan50A 的类,其命名空间为 BusinessLayer.FilterElements.FilterRandom 和一个名为 RunFilter() 的公共静态方法;
在使用此方法的网站的代码隐藏页面中,我有 using 语句,Using BusinessLayer。我还有另一个 using 语句,使用 BusinessLayer.FilterElements。
我认为要公开 LessThan10DaysGreaterThan50A 类的 RunFilter() 方法,我可以使用以下语法:FilterRandom.LessThan10DaysGreaterThan50A.RunFilter(),但是我收到以下错误:名称 FilterRandom 在当前上下文中不存在。
如果我内联使用以下语法,则错误消失:BusinessLayer.FilterElements.FilterRandom.LessThan10DaysGreaterThan50A.RunFilter(),或者如果我使用以下 using 语句:使用 BusinessLayer.FilterElements.FilterRandom,则以下语法有效:LessThan10DaysGreaterThan50A.RunFilter( )。
我宁愿使用 FilterRandom.LessThan10DaysGreaterThan50A.RunFilter() 因为它似乎使代码更具可读性。如果我使用具有以下语法的别名:使用 FilterRandom = BusinessLayer.FilterElements.FilterRandom,我可以得到我想要的,但我不太喜欢使用别名的想法,因为它可能会导致混乱。
我认为由于我的 BusinessLayer 命名空间具有嵌套命名空间,我能够选择剩余的命名空间,但我似乎无法让它工作。有人知道如何在不使用别名的情况下完成这项工作,还是我每次都必须使用整个命名空间名称?
谢谢。
Ok, I have a c# project named BusinessLayer which produces an assembly called BusinessLayer and the namespace is BusinessLayer.
Inside of this project, I am using folders to store code. One folder is called FilterElements and it has folders called FilterKeyReversal, FilterRandom and FilterToday.
Let's take the example of the FilterRandom folder. It has a class called LessThan10DaysGreaterThan50A with a namespace of BusinessLayer.FilterElements.FilterRandom and a single public static method called RunFilter();
In the code behind page of the website that is consuming this method, I have the using statement, Using BusinessLayer. I also have another using statement, using BusinessLayer.FilterElements.
I would think that to expose the RunFilter() method of the LessThan10DaysGreaterThan50A class, I could use the following syntax: FilterRandom.LessThan10DaysGreaterThan50A.RunFilter(), however I get the following error: The name FilterRandom does not exist in the current context.
If I use the following syntax inline, the error goes away: BusinessLayer.FilterElements.FilterRandom.LessThan10DaysGreaterThan50A.RunFilter(), or if I use a using statement of: Using BusinessLayer.FilterElements.FilterRandom, the following syntax works: LessThan10DaysGreaterThan50A.RunFilter().
I would rather use FilterRandom.LessThan10DaysGreaterThan50A.RunFilter() as it seems to make code more readable. If I use an alias with the following syntax of using FilterRandom = BusinessLayer.FilterElements.FilterRandom, I can get what I want, but don't really like the idea of using an alias since it can lead to confusion down the line.
I thought that since my BusinessLayer namespace has nested namespaces, I'd be able to pick up the remaining namespace, but I can't seem to get it to work. Anybody know how to make this work without using an alias, or am I going to have to use the entire namespace name every time?
Thanks.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
不,事实并非如此。我知道这很烦人。
我第一次尝试解决这个问题(我有同样的问题)是添加这些用法:
然后问题就变成了你必须为你想要包含的每个子命名空间添加一个,并且变得一团糟。
我如何永久解决这个问题是通过更改项目中的命名空间,以便在您的示例中,
FilterRandom
例如位于BusinessLayer
中。您实际看到的问题是您有太多名称空间。发生这种事并不奇怪。它们是组织代码和类的好方法,并且让它失控并不难。我所说的更改命名空间的意思是,我将许多小的命名空间合并到更大的命名空间中。这有时意味着重命名类,但我认为类名本身应该是有意义的,没有命名空间前缀。
通过这种方式,我在我的项目(60kloc)中永久解决了这些问题,并且效果很好。
Nope, it doesn't. I know it's very irritating.
My first try at solving this issue (I had the same issue) was adding these usings:
The problem then becomes that you have to add one for every sub namespace you want to include, and that becomes a mess.
How I permanently solved this is by changing the namespaces in the project so that, in your example,
FilterRandom
would e.g. be inBusinessLayer
.The problem you are actually seeing is that you have too many namespaces. It isn't strange it happens. They are a great way of organizing your code and classes and it's not that hard to have it go out of hand. What I mean by changing the namespaces is that I merged many small namespaces into larger ones. This sometimes means renaming classes, but my opinion is that the class name on itself should be meaningful, without the namespace prefix.
This way, I permanently solved these issues in my project (60kloc) and it worked out great.