在过去，我总是离开并为特定项目调用我的命名空间，与项目（和原则类）相同，例如：
namespace KeepAlive
{
public partial class KeepAlive : ServiceBase
{...
然后在其他项目中，每当我打电话给那个班级时，它始终是：
KeepAlive.KeepAlive()...
我现在开始认为这可能不是一个好主意，但我有点难以实际调用我的命名空间。其他人做什么？您是否只为所有项目设置了一个命名空间？
答案 0 :(得分：7)
让一个类的名称与命名空间相同是一个坏主意 - 在我看来，在某些情况下引用正确的东西是非常棘手的。
我通常将项目（和命名空间）称为适当的名称，然后在适当的位置使用“EntryPoint”或“Program”作为入口点。在您的示例中，我可能会将类称为“KeepAliveService”。
答案 1 :(得分：7)
我们有这个简单的方案：
CompanyName.ProductName
然后是应用层，例如
CompanyName.ProductName.Data
CompanyName.ProductName.Web
等
内部分为每个模块和/或功能，通常对应于文件夹
CompanyName.ProductName.Web.Shop
CompanyName.ProductName.Web.Newsletter
等
顺便说一句：你可以在这里找到类似问题的答案：
答案 2 :(得分：5)
CompanyName.ProductName.AreaOfSystem.SubAreaOfSystem
永远不要将它们称为与班级相同的名称。
我们的领域包括：
子区域被谨慎使用但在相关时使用：
我们不对应文件夹，因为逻辑上可能不是这种情况。为了简化解决方案资源管理器导航，我们可能会删除文件夹中的某些位，但这并不一定意味着命名空间应该遵循文件夹结构。特别是如果文件夹中只有少数文件（具有少量类型的命名空间通常是愚蠢的）。
答案 3 :(得分：3)
我使用进入该命名空间的所有内容的公共描述符命名我的命名空间。
答案 4 :(得分：0)
我喜欢java包的方式：com.stackoverflow.Data（或者贵公司的主要域名可能是什么）。
这样你的命名空间就不会有歧义。
答案 5 :(得分：0)
我们坚持旧的
uk.co.company.system.layer
方案，因为我们使用大量的MS Server产品，因此我们将冲突保持在最低限度，这有助于概念分离。
例如
uk.co.acme.biztalk.bizutils。