在过去，我一直走了，叫我的名字空间的特定项目一样的项目（和原理类），例如最好的事情：什么是打电话给你的命名空间的.Net
namespace KeepAlive
{
public partial class KeepAlive : ServiceBase
{...
然后从每当我调用这个类的其他项目的始终是：
KeepAlive.KeepAlive()...
现在我开始认为这可能不是一个好主意，但我有点难倒什么实际打电话给我命名空间。其他人做什么？你是否只有一个名称空间用于所有项目？
我们有这个简单的方案：
CompanyName.ProductName
然后应用层，例如
CompanyName.ProductName.Data
CompanyName.ProductName.Web
等
而且内部划分每个模块和/或功能，这通常对应于文件夹
CompanyName.ProductName.Web.Shop
CompanyName.ProductName.Web.Newsletter
等
BTW：你可以找到答案类似的问题这里：
我用名称空间中所有事物的通用描述符命名我的名称空间。
将类的名称与命名空间相同是一个坏主意 - 在我看来，在某些情况下引用正确的东西非常棘手。
我通常会调用项目（和名称空间）一个合适的名称，然后在适当的位置为入口点提供“EntryPoint”或“Program”。在你的例子中，我可能会调用类“KeepAliveService”。
CompanyName.ProductName.AreaOfSystem.SubAreaOfSystem
从来没有打电话给他们相同的名称为一类。
我们的领域包括了诸如：
子区是谨慎使用，但如果相关：
我们不对应于文件夹，因为在逻辑上可能不是这种情况。为了缓解解决方案浏览器的导航，我们可能在文件夹部分关闭某些位，但这并不一定意味着该命名空间应遵循的文件夹结构。特别是如果文件夹中只有少量文件（一个类型很少的命名空间通常很愚蠢）。
我喜欢的java包方式：com.stackoverflow.Data（或whatwever贵公司的主域名而定）。
这样，你的命名空间也不会含糊。
我们坚持到老
uk.co.company.system.layer
方案这样，我们不断的冲突降到miniumum因为我们使用了很多的MS服务器产品，它可以帮助概念seperations 。
例如。
uk.co.acme.biztalk.bizutils。
我们非常相似。 +1！当该公司名称变更，有合并或产品名称的变化 – 2008-11-14 12:57:13