我有3个图书馆：
旨在与数据访问层通信的业务对象。每个类都有一个属性（long类型），它对应于数据库实体的主键。
将这些业务对象传达回DAL的中间层业务逻辑层
与UI通信的数据传输对象（DTO）库。在查看，更新或删除之前，业务逻辑层将DTO上的主键属性验证为零值。
一位程序员（对数据库开发更有经验）抱怨这相当于“NULL不为零”。他希望将所有DTO上的ID更改为Nullable，但将Ids留在业务对象（与DAL通信）上。另一个程序员认为针对主键验证零是有效的，因为零不是任何实体的有效主键。
“NULL不为零”参数是否适用于此方案？是否是“最佳实践”，DTO上的所有ID都被转换为Nullable，但在被验证为不为null之后传递给业务对象？
让我在上面的问题中添加更多信息。
应用程序数据库编程的标准很久以前就已经设计好了，不能随时改变。数据库具有用户定义的类型： CREATE TYPE [dbo]。[PKIdentifier] FROM [bigint] NOT NULL
每个表都有一个主键定义，如下所示： [Program_ID] [dbo]。[PKIdentifier] IDENTITY（1,1）NOT NULL
换句话说，所有主键都是长Identity（1,1）。然而，在构建业务逻辑层时，我不希望它假设有关数据层实现的任何知识。
编写中间层是为了检查零，因为业务对象（使用主键属性的数据类型定义）只能为某些命令（如CREATE）的任何非持久实体的主键接受零。 。集成测试还检查业务对象类的主键属性中的非零值，作为CREATE命令成功的指示。该应用程序工作。我只关心最佳实践和代码质量。
测试是否基于检查主键值大于零的良好做法？请注意，业务库未打开进行修改，并且主键属性的数据类型只有long。是否应修改业务对象以允许可为空，并相应地修改DAL以处理Nullable属性以维持“最佳实践”？或者对于这种情况没有这样的“最佳实践”？