我将所有字段设置为可空类型,其中后端数据库字段对应于允许空值。好?坏?
长版:
它运作得很好,我只是觉得我可能会滥用这个事实,我可以把东西弄为空。
基本上,它是一个与我们的SQL数据库相关联的员工管理的内部应用程序。我使用的是三层结构,从演示到后端:Business Objects - >业务逻辑 - >数据访问。
对于我的Employee对象,我有以下字段:
public class Employee : Person
{
private EmployeeTitle? _employeeTitle = null; //enum
private EmployeeType _employeeType; //enum
private DateTime _startDate;
private DateTime? _endDate = null;
private EmployeeInsuranceRecord _employeeInsuranceRecord = new EmployeeInsuranceRecord();
//...
}
public class EmployeeInsuranceRecord
{
private int? _employeeInsuranceRecordID = null;
private string _alienRegistrationNumber = null;
private string _healthInsuranceNumber = null;
private string _unemploymentInsuranceNumber = null;
private string _welfarePensionNumber = null;
private DateTime? _insuranceAcquiredDate = null;
//...
}
在我的数据库中:
EmployeeTitleID允许空值。例如,员工可以在试用期内开始,没有固定的职位。
EmployeeTypeID不允许空值。即使员工是客人或在试用期内,也必须明确选择此类用于记录目的。
StartDate不允许空值。如果有人进入数据库,我们需要知道他们什么时候开始。
然而,EndDate确实允许空值。目前就业的任何人都没有EndDate。
我在Employee实例化上实例化一个EmployeeInsuranceRecord对象,但EmployeeInsuranceRecord中的每个字段都可以为空,因为EmployeeInsuranceRecords进入一个通过ID链接的单独表,因此Employee可以在没有EmployeeInsuranceRecord的情况下存在(对于刚启动的人来说很常见)仍然在最初的文书工作过程中)。通过从一开始就实例化EmployeeInsuranceRecord,我可以通过不在那里实例化任何类来保持我的表示层更清晰。考虑到我们正在进行的小规模,这对性能没有影响。
答案 0 :(得分:3)
null的一个烦恼是在取消引用/消耗值之前继续检查null的编码开销 - 您可能需要使用一堆静态扩展方法来使您的生活更轻松。
但是使用null比使用像DateTime.MinValue这样的“魔术值”更好 - 这不仅会破坏数据,而且如果您忘记将其映射回null,则在持久保存到数据库时可能会出现问题。
正如您所描述的那样,某些值成为强制性的,因为它们是“状态”依赖的(例如,当员工辞职/退休/被解雇时需要EndDate)。您需要根据此分离出验证策略。
答案 1 :(得分:2)
使字段可以为空是表示业务数据所必需的。你在做什么看起来很好。
答案 2 :(得分:2)
您正确建模数据库。我甚至会说,如果你不在这里使用可空类型,你就会在代码中引入错误。
答案 3 :(得分:0)
当数据库表列定义为可空类时,必须使用可空类型。否则,您将无法将模型属性与数据库列匹配。
除了在性能方面,没有区别,你不必担心使用可空或不可空类型
答案 4 :(得分:0)
如果属性或字段不是必需的,则应该只允许空值。否则,您应该想出一种让用户指定值或设置默认值的方法(您也可以对非强制性字段的字段执行此操作)。如果你指定的代码反映了许多字段是可选的情况,那就好了。虽然我有点想知道为什么你有可空的枚举....