poll:您将什么称为业务层基本名称空间?

我将删除“layer”后缀:mycompany.myproduct.business

我们只使用BL,因为它代表业务层和budlight。

过去我把它叫做“生意”。

我做client.project.businessobjects

在爪哇,我使用 com.companyname.applicationname.* “标准”,尽管有点老派。

在C中,我使用 CompanyName.ApplicationName.* 方法。

在两种情况下 * 通常是 business 对于业务层, data 对于数据层,等等。

我们的业务逻辑和数据访问层

公司名称.applicationname.bll 公司名称.applicationname.dal

另一种选择可能是busobj或类似的东西。

公司.产品.功能域.biz

我看过《商业逻辑》,但正如下面的答案所指出的,你会看到很多时间…

• mycompany.myproduct.dataaccesslayer(或dal)
• mycompany.myproduct.businessEntities(或BusinessObjects)
• mycompany.myproduct.businesslogic公司
• mycompany.myproduct.web.service公司
• mycompany.myproduct.web.site网站

另一个很好的参考资料是 Framework Design Guidelines 书。

我们工作的大多数应用程序使用DAL作为数据访问层,使用BR作为业务规则…

我们的是:

CompanyName.CentralClassLibrary
CompanyName.Utilities.*
CompanyName.TradingTools.*

第一个类主要来自我们应用程序的原始版本,它描述了中央交易对象。第二类是提供非交易特定功能(配置、多台机器等)的类;第三类是特定交易领域(我们交谈的每个服务一个,计算价值一个等)。

为什么要在一对一关系中直接将层映射到名称空间?分层是一种分离复杂软件系统的技术。它是一种观察主要子系统排列的方式,就像蛋糕一样,每一层都位于较低的层上。较高的层使用较低层的服务,但较低的层不知道较高的层。一个应用程序可以很容易地拥有每个主题领域(表示、业务、数据源)的多个包。

例如,在Web应用程序中,HTML和CSS是表示层的一部分,但这两个文档都不会驻留在mycompany.myproduct.presentation layer命名空间中。

所以,要回答您的问题,您将什么称为业务层基本名称空间?_绝对没有。这样的名称空间不应该存在。命名空间应按功能命名。 业务层 是 不 一个特点都不是 表示层、数据层或服务层 .

就我的两块。