我有一个简单的解决方案，其中包括以下项目（基础命名空间与项目名称匹配）...
MyCompany.MyProduct.BusinessLayer
MyCompany.MyProduct.Web.Service
MyCompany.MyProduct.Web.Site
我只是想为BusinessLayer找一个更好的名字，我只是因为某种原因不喜欢它。所以我的问题是你如何称呼你的BusinessLayer项目/命名空间。
有关命名空间指南的文章 http://msdn.microsoft.com/en-us/library/ms229026.aspx
答案 0 :(得分：5)
我会删除“Layer”后缀：MyCompany.MyProduct.Business
答案 1 :(得分：5)
我们只使用BL，因为它代表Business Layer和BudLight。
答案 2 :(得分：1)
过去我刚才称它为“商业”。
答案 3 :(得分：0)
我们的是：
CompanyName.CentralClassLibrary
CompanyName.Utilities.*
CompanyName.TradingTools.*
第一个主要是来自我们应用程序原始版本的类，它描述了中央交易对象。第二个是提供非交易特定功能的类（配置，多机器等）。第三个是针对特定交易领域（一个用于我们交谈的每个服务，一个用于计算价值等）。
答案 4 :(得分：0)
我做Client.Project.BusinessObjects
答案 5 :(得分：0)
在Java中，我使用com.companyname.applicationname.*“标准”，即使它是一个小老派。
在C＃中，我使用CompanyName.ApplicationName.*方法。
在这两种情况下，*通常为业务层business，数据层为data，依此类推。
答案 6 :(得分：0)
我们的业务逻辑和数据访问层
CompanyName.ApplicationName.BLL CompanyName.ApplicationName.DAL
替代方案可能是BusObj或类似的东西。
答案 7 :(得分：0)
Company.Product.FunctionalDomain.Biz
答案 8 :(得分：0)
我见过BusinessLogic，但正如其他答案所指出的那样，很多时候你会看到......
这类东西的另一个很好的参考是Framework Design Guidelines书。
答案 9 :(得分：0)
我们处理的大多数应用都使用DAL进行数据访问层，使用BR进行业务规则...
答案 10 :(得分：0)
为什么首先以与命名空间一对一的关系直接映射图层？分层是一种分解复杂软件系统的技术。这是一种看待主要子系统像蛋糕排列的方式，每个层都位于较低层。较高层使用较低层的服务，但较低层不知道较高层。应用程序可以轻松拥有每个主题领域（演示文稿，业务，数据源）的多个包。
例如，在Web应用程序中，HTML和CSS是表示层的一部分，但这些文档都不会驻留在MyCompany.MyProduct.PresentationLayer命名空间中。
所以，回答你的问题“你称之为业务层基础命名空间是什么？”绝对没有。这样的命名空间不应该存在。命名空间应按功能命名。 业务层 不一项功能。 表示层，数据层或服务层。
只是我的两位。