命名约定DAL，BAL和UI层

我正在开发具有以下几层的典型Web应用程序

1. UI层（MVC）
2. 业务逻辑层（BAL）
3. 数据访问层（DAL）

每个层都有自己的DTO对象，包括BAL和DAL。我对此的疑问如下

1. DAL返回的DTO只需转换为BAL中的相应DTO，然后发送到UI层即可。在某些情况下，DTO对象的属性和结构都是相同的。在这种情况下，最好将DAL中的DTO简单地返回到UI层而不包含中间对象。

2. 命名这些DTO对象和每一层中其他对象的最佳方法是什么。我应该使用一些前缀，例如DTOName，ServiceName吗？我之所以要求使用前缀的原因是，如果解决方案中的类与Framework中的其他类以及前缀不冲突，那么我更容易理解每​​个类所属的位置吗？

前言

希望这是显而易见的，但是......在下面的建议命名空间，应更换MyCompany，并MyProject与贵公司和项目的实际名称。

DTO

我建议在所有层上使用相同的DTO类。这样可以减少维护点。我通常将它们放在MyCompany.MyProject.Models同名VS项目中的命名空间下。我通常以它们所代表的真实世界实体的名字来命名。（理想情况下，数据库表也使用相同的名称，但有时在此处设置模式略有不同是有意义的。）

例如：Person，Address，Product

依赖关系：无（标准.NET或帮助程序库除外）

DAL

我个人的喜好是在MyCompany.MyProject.DataAccess命名空间/项目中使用与DTO类匹配的一对一DAL类。此处的类名以Engine后缀结尾，以避免冲突。（如果您不喜欢该术语，那么DataAccess后缀也可以正常工作。只要与您选择的内容保持一致即可。）每个类都提供简单的CRUD选项访问数据库，对大多数输入参数和返回类型使用DTO类（内部List如果有多个（例如，Find()方法返回），则为通用。

例如：PersonEngine，AddressEngine，ProductEngine

依存关系： MyCompany.MyProject.Models

平衡/平衡

这里也是一对一的映射，但是在MyCompany.MyProject.Logic名称空间/项目中，并且类具有Logic后缀。这应该是调用DAL 的唯一层！这里的类通常只是到DAL的简单传递，但是如果＆当需要实现业务规则时，就在这里。

例如：PersonLogic，AddressLogic，ProductLogic

依赖关系：MyCompany.MyProject.Models，MyCompany.MyProject.DataAccess

API

如果有一个Web服务API层，我将使用相同的一对一方法，但是在MyCompany.MyProject.WebApi名称空间/项目中，使用Services类后缀。（除非您使用的是ASP.NET Web API，否则在这种情况下您当然会使用Controller后缀）。

例如：PersonServices，AddressServices，ProductServices

相关性：MyCompany.MyProject.Models，MyCompany.MyProject.Logic（永远不要通过直接调用DAL来绕过它！）

业务逻辑观察

人们似乎越来越普遍地忽略了BAL / BLL，而是在最有意义的地方，在一个或多个其他层中实现业务逻辑。如果执行此操作，则绝对要确保（1）所有应用程序代码都经过具有业务逻辑的层，并且（2）在实现每个特定业务规则的地方都显而易见和/或有据可查。如有疑问，请勿在家中尝试。

关于企业级架构的最终说明

如果您在大型公司中，或者在同一情况下跨多个应用程序共享同一数据库表，那么我建议您将上述MyProject部分放在上述名称空间/项目之外。这样，这些层可以被多个前端应用程序（以及Windows Services等幕后实用程序）共享。但是，只有在拥有强大的跨团队沟通和适当的自动化回归测试的情况下，才可以这样做！！！否则，一个团队对共享核心组件的更改可能会破坏另一团队的应用程序。

我通常将应用程序构建为

ProjectName.Core            // "framework"/common stuff
|- Extenders
|- Gravatar.cs

ProjectName.DataProvider    // database provider layer
|- Migrations
|- ApplicationDbContext.cs  // entity framework

ProjectName.Domain          // database objects
|- Post.cs
|- Tag.cs

ProjectName.Services        // validations, database stuff
|- PostService.cs

它有点类似于Sharp-Lite。

关于前缀，我讨厌它们。微软的《内部编码指南》也讨厌它们。还有一个名为StyleCop的工具，它也会抱怨前缀。