在ABP.IO中建模已注册与未注册用户并避免属性重复的方案咨询

嘿，这个场景我之前在几个ABP.IO迁移项目里碰到过，刚好能给你分享几个实用的设计方案，既能清晰区分注册/未注册用户，又能避免属性重复冗余～

方案一：抽象基类+双实体（推荐，符合DDD设计） #

这种方式通过抽象基类复用公共属性，再用两个具体实体分别对应注册用户和访客，逻辑清晰且扩展性强：

1. 先定义抽象基类，存放所有公共属性：

public abstract class Customer : FullAuditedAggregateRoot<Guid>
{
    public string Email { get; set; }
    public string FullName { get; set; }
    public string PhoneNumber { get; set; }
    // 其他业务通用属性，比如收货地址等
}

2. 注册用户实体关联ABP自带的IdentityUser：

public class RegisteredCustomer : Customer
{
    public Guid IdentityUserId { get; set; }
    public IdentityUser IdentityUser { get; set; } // 导航属性关联系统身份用户

    // 无需重复公共属性，直接继承自Customer
}

3. 访客实体添加特有的属性：

public class GuestCustomer : Customer
{
    // 访客专属属性，比如临时验证Token、是否已转化为注册用户等
    public string TemporaryToken { get; set; }
    public bool IsConverted { get; set; } = false;
}

4. 订单实体直接关联抽象基类，统一处理两种用户：

public class Order : FullAuditedAggregateRoot<Guid>
{
    public Guid CustomerId { get; set; }
    public Customer Customer { get; set; }
    // 订单其他业务属性
}

优势：完全贴合DDD聚合根设计，公共属性只维护一次，两种用户类型边界清晰，后续扩展访客转注册、跨订单复用访客信息等需求都很方便。

方案二：值对象存储访客信息（轻量方案） #

如果你的业务逻辑不复杂，不需要单独维护访客实体，可以用值对象存储访客信息，同时让订单关联注册用户：

public class Order : FullAuditedAggregateRoot<Guid>
{
    // 关联注册用户（可为空，访客订单则为null）
    public Guid? IdentityUserId { get; set; }
    public IdentityUser IdentityUser { get; set; }

    // 访客信息值对象（注册用户订单则为null）
    public GuestInfo GuestInfo { get; set; }

    // 标记用户类型，方便业务判断
    public UserType UserType { get; set; }
}

// 用户类型枚举
public enum UserType
{
    Registered,
    Guest
}

// 访客信息值对象
public class GuestInfo : ValueObject
{
    public string Email { get; set; }
    public string FullName { get; set; }
    public string PhoneNumber { get; set; }

    protected override IEnumerable<object> GetEqualityComponents()
    {
        yield return Email;
        yield return FullName;
        yield return PhoneNumber;
    }
}

优势：实现简单，不需要额外维护实体表，适合访客仅关联单次订单的场景；缺点是无法复用访客信息，后续如果需要支持访客多次下单就会比较麻烦。

方案三：扩展IdentityUser自定义字段（不推荐） #

ABP.IO允许给系统自带的IdentityUser添加自定义字段，但这种方式没法区分注册用户和访客——因为访客本身不是系统的身份用户，只能把访客信息存在其他表或字段里，容易造成数据混乱，仅适合访客后续必须转化为注册用户且业务逻辑非常简单的场景。

额外注意点 #

• 用方案一时，记得在ABP的DbContext中配置实体继承映射（EF Core默认使用TPH单表继承，配置简单）；
• 访客转注册用户的场景，方案一可以直接将GuestCustomer转化为RegisteredCustomer，或者新建RegisteredCustomer并关联原访客的订单（根据业务需求选择）；
• 权限控制上，注册用户用ABP自带的身份权限体系，访客可以通过临时Token或匿名权限验证。

备注：内容来源于stack exchange，提问作者Juraj Majerech