代码之家 › 专栏 › 技术社区 › uriDium

对于N层架构中的业务层命名约定,是否有任何最佳实践或指南?

n-tier-architecture naming-conventions

2

uriDium · 技术社区 · 15 年前

我们正在考虑为即将开始的项目使用N层架构。我只是想了解一下命名约定。我读了几本书,在网上做了一些研究,但是我仍然在努力为那些做你的基本积垢的对象找到一个合适的名称。一本书使用了后缀逻辑。因此,如果处理的是产品,那么业务层有一个名为ProductLogic的对象,它是您得到、更新等的,我不太喜欢这种命名约定。

另一个资源建议使用后缀管理器。所以我们将使用ProductManager。我不喜欢这个名字,因为这个名字在任何时候都不能真正说明它的作用。好像有点模棱两可。

我正在努力使我的班级的责任保持良好和独立。所以我们有数据访问对象,它只做数据访问。我们在单独的类中也有验证器。“经理”负责协调验证和数据访问。

当涉及到业务逻辑层对象时,它们是否有任何类型的命名约定?

1 回复 | 直到 15 年前

1

0

Douglas 15 年前

我最近使用的是数据传输对象的后缀dto。业务层中有趣的代码是以它们的用途命名的,没有后缀/前缀。我们使用的是NHibernate,所以这些对象除了ID字段之外没有任何特定的方法或属性。