业务对象适配展示层重复定义属性的优化方案咨询

你当前的方案本质是破坏了分层架构的职责边界，把UI层的展示逻辑耦合进了核心领域实体，长期维护会遇到很多问题，更合理的实现方式如下：

你当前在EmployeeWorkShift领域实体中新增格式化字符串属性的做法，会带来三个明显的隐患：

• 实体存在两套同源的日期时间数据，只要修改其中一套忘了同步另一套，就会出现数据不一致，排查问题成本极高
• 如果后续不同UI场景需要不同的日期时间格式（比如PC端用yyyy/MM/dd、移动端用MM月dd日），就得不停往实体里加字符串属性，核心类会越来越臃肿
• 核心业务层、仓储层被迫依赖UI展示规则，分层边界被打破，后续调整业务逻辑或者更换UI都会互相牵连

核心原则是保持领域实体纯净，UI相关逻辑完全隔离在核心业务层之外，具体落地分三步：

1. 保留原始领域实体的纯净性 #

不要给核心的EmployeeWorkShift类加任何UI相关属性，它只承载核心业务数据，完全不关心格式化、展示相关的需求，保留原始定义即可：

using System;

namespace BusinessObjects
{
  public class EmployeeWorkShift
  {
    public long EmployeeWorkShiftId { get; set; }
    public long EmployeeId { get; set; }
    public DateTime StartDate { get; set; }
    public DateTime EndDate { get; set; }
    public TimeSpan StartTime { get; set; }
    public TimeSpan EndTime { get; set; }
  }
}

仓储、服务层的核心增删改查逻辑，全部围绕这个纯净的实体实现，不要掺杂任何格式转换代码。

2. 为UI场景单独定义专属模型 #

针对UI的展示、输入需求，单独定义专门的视图模型（ViewModel/Request DTO），这个模型只服务于当前交互场景，和核心领域实体完全解耦：

using System;

namespace UiContracts
{
  public class EmployeeWorkShiftVm
  {
    public long EmployeeWorkShiftId { get; set; }
    public long EmployeeId { get; set; }
    // 仅UI使用的格式化字符串字段
    public string StartDateString { get; set; }
    public string EndDateString { get; set; }
    public string StartTimeString { get; set; }
    public string EndTimeString { get; set; }
  }
}

对应调整服务层对外暴露的方法签名，所有和UI交互的入口、出口都使用这个专属模型，而不是直接返回/接收核心领域实体：

• 查询类方法返回EmployeeWorkShiftVm或者List<EmployeeWorkShiftVm>
• 新增、更新类方法接收EmployeeWorkShiftVm作为入参

3. 统一收敛格式转换逻辑 #

把领域实体和UI模型之间的转换、格式校验逻辑，抽成独立的映射方法集中维护，不要散落在各个服务方法里。参考实现：

using System.Globalization;

public static class EmployeeWorkShiftConverter
{
  // 统一配置UI需要的固定格式，后续改格式只需要改这里
  private const string TargetDateFormat = "yyyy-MM-dd";
  private const string TargetTimeFormat = @"hh\:mm";

  public static EmployeeWorkShiftVm ToVm(this EmployeeWorkShift entity)
  {
    return new EmployeeWorkShiftVm
    {
      EmployeeWorkShiftId = entity.EmployeeWorkShiftId,
      EmployeeId = entity.EmployeeId,
      StartDateString = entity.StartDate.ToString(TargetDateFormat),
      EndDateString = entity.EndDate.ToString(TargetDateFormat),
      StartTimeString = entity.StartTime.ToString(TargetTimeFormat),
      EndTimeString = entity.EndTime.ToString(TargetTimeFormat)
    };
  }

  public static EmployeeWorkShift ToDomainEntity(this EmployeeWorkShiftVm vm)
  {
    // 转换时统一做格式校验，不合法直接抛出明确的校验错误给UI
    if (!DateTime.TryParseExact(vm.StartDateString, TargetDateFormat, CultureInfo.InvariantCulture, DateTimeStyles.None, out var startDate))
      throw new ArgumentException("开始日期格式不符合要求");
    if (!DateTime.TryParseExact(vm.EndDateString, TargetDateFormat, CultureInfo.InvariantCulture, DateTimeStyles.None, out var endDate))
      throw new ArgumentException("结束日期格式不符合要求");
    if (!TimeSpan.TryParseExact(vm.StartTimeString, TargetTimeFormat, CultureInfo.InvariantCulture, out var startTime))
      throw new ArgumentException("开始时间格式不符合要求");
    if (!TimeSpan.TryParseExact(vm.EndTimeString, TargetTimeFormat, CultureInfo.InvariantCulture, out var endTime))
      throw new ArgumentException("结束时间格式不符合要求");

    return new EmployeeWorkShift
    {
      EmployeeWorkShiftId = vm.EmployeeWorkShiftId,
      EmployeeId = vm.EmployeeId,
      StartDate = startDate,
      EndDate = endDate,
      StartTime = startTime,
      EndTime = endTime
    };
  }
}

服务层的逻辑会非常清晰：

• 处理查询请求时，从仓储拿到领域实体，调用ToVm()转成UI模型返回即可
• 处理新增、更新请求时，先把收到的UI模型调用ToDomainEntity()转成合法的领域实体，做完业务校验后再交给仓储持久化

• 职责边界清晰：核心领域层完全不感知UI的格式要求，后续调整业务逻辑、修改UI展示格式互不影响
• 没有数据一致性风险：领域实体里只有一套权威的日期时间值，格式化字符串只是交互过程中的临时数据，不会和核心数据混存
• 扩展性强：如果后续其他端需要不同的日期格式，只需要新增对应端的模型和转换逻辑即可，不需要修改核心领域实体、服务、仓储的代码
• 维护成本低：格式配置、校验逻辑全部集中在转换类里，排查问题、调整规则都不需要翻零散的业务代码

如果是规模很小的项目，不想单独拆分项目放UI模型，哪怕把VM定义在服务层里也可以，核心原则不变：永远不要让核心领域对象承载和业务无关的UI展示逻辑。

内容的提问来源于stack exchange，提问作者srh