AggregateRootRepository<T> 聚合根的仓储，新规则欢迎讨论~~

[2881099]

我的想法是利用聚合根的特点，做这个功能不知道行不行的通。主要看实用性，会不会变成鸡肋，以及我没考虑到的情况。如果你有想法，欢迎留言~~~谢谢！！

FreeSql.Repository 定义了 IBaseRepository 仓储接口，实现了单表的通用仓储对象，支持了级联保存、级联删除功能，使用时需要人工自己判断何时开启、何时使用。

AggregateRootRepository 是 IBaseRepository 一种新的尝试实现，它将自动处理 OneToOne/OneToMany 导航属性，以及 ManyToMany 中间表的级联添加、级联更新、级联删除、级联查询（查询时自动 Include/IncludeMany 它们）。

var repository = fsql.GetAggregateRootRepository<Order>();

详细的机制与说明：聚合根（实验室）

[hd2y]

简单说一下之前群里提到的疑惑：

IFreeSql freeSql = new FreeSqlBuilder()
    .UseConnectionString(DataType.Sqlite, "Data Source=:memory:;")
    .UseAutoSyncStructure(true)
    .Build();

freeSql.CodeFirst.SyncStructure(typeof(BizOrder), typeof(SysUser));
var tableRef = freeSql.CodeFirst.GetTableByEntity(typeof(BizOrder)).GetTableRef(nameof(BizOrder.CreatedUser), false);
tableRef.Dump();
//var tableRef1 = freeSql.CodeFirst.GetTableByEntity(typeof(SysUser)).GetTableRef(nameof(SysUser.CreatedOrders), false);
//tableRef1.Dump();

public class BizOrder
{
    public Guid Id { get; set; }
    public string Code { get; set; }

    public DateTime? CreatedAt { get; set; }
    public Guid? CreatedUserId { get; set; }
    [Navigate(nameof(CreatedUserId))]
    public SysUser CreatedUser { get; set; }

    public DateTime? ModifiedAt { get; set; }
    public Guid? ModifiedUserId { get; set; }
    [Navigate(nameof(ModifiedUserId))]
    public SysUser ModifiedUser { get; set; }
}

public class SysUser
{
    public Guid Id { get; set; }
    public string Code { get; set; }
    public string Name { get; set; }

    // 正常应该不会在参数表配置这种导航关系
    //[Navigate(nameof(BizOrder.CreatedUserId))]
    //public List<BizOrder> CreatedOrders { get; set; }
    //
    //[Navigate(nameof(BizOrder.ModifiedUserId))]
    //public List<BizOrder> ModifiedOrders { get; set; }
}

测试发现默认情况下 BizOrder 与 SysUser 就是 ManyToOne 的关系，所以之前对于会不会错误更新或删除 SysUser 表数据的担心是多余的。

[sgf]

AggregateRootBoundary 需要调用 arrRepo.ChangeBoundary(); 太麻烦
希望支持 直接标记即生效.

[2881099]

为了解决同一套实体类，不同的边界规则，例如两个同事都做了实体的 crud，公用一套规则可能存在冲突，同事A希望更新某导航属性，同事B不希望。

[sgf]

为了解决同一套实体类，不同的边界规则，例如两个同事都做了实体的 crud，公用一套规则可能存在冲突，同事A希望更新某导航属性，同事B不希望。

这个需求太扯了。存在分歧的导航属性，就应该手动更新。

[sgf]

为了解决同一套实体类，不同的边界规则，例如两个同事都做了实体的 crud，公用一套规则可能存在冲突，同事A希望更新某导航属性，同事B不希望。

举个例子，A同事想要用FreeSql，B同事想要用SqlSugar。必须统一用FreeSql或者SqlSugar其中的一个，而不是让他们各自为战。

[ycbb]

按照标准的DDD严格定义来说，凡是聚合根下的实体属性，以及这个实体属性中包含关联的实体，应该均属于领域边界内的，有着共同的生命周期，如果这样界定的话，其实导航属性作用就不大了，有没有导航属性，都要统一的增删改。
举例来说，如果定义一个User实体，User中包含了一个Roles的集体，那么，这个User和他所分配的Role是共生的，User如果删除了，那么这些Roles也要删除。因为当开发者把Role这个实体做为User聚合的一部分时，就代表了Role从属于User的聚合。当然，实际情况不能这样，Role是独立的，应该是另外一个聚合根，那么Role就不能以实体属性的方式出现在User中，而应该以聚合根标识的集合，也就是id集合定义在User中。这样，对User的增删就不会影响Role。
这是严格按照DDD聚合根的概念来说，如果真的应用DDD，我觉得还是遵循这个严格定义。这样的话，边界的问题就很好解决，抛开技术的实现难度来说，应该就是：凡是聚合根边界内的实体，均要处理，哪怕是多对多的情况，也要该增的增，该删的删，而不是只增不删。
当然，我承认这有点教条主义了，不过，我想既然要用DDD了，按照定义把实体设计的严格一点，又有何妨呢？从设计层面解决边界问题，而不是依赖于技术，更有利于项目的健康。
再举一个例子，一家银行系统，作为登录用户，有个User实体，那么，当需要开卡了，一般情况下，省事，会直接关联这个User取得用户信息，那么，从领域设计角度来说，登录用户，和开卡的用户其实属于两个业务领域，我们还需要一个CardUser，这个CardUser是User一个子集，甚至完全和User相同也可，那么，新增开卡用户的时候，是把某个用户的数据，从User表中复制到CardUser表，而不是关联起来，这样，就能很好处理边界了，因为，我删除CardUser表中的数据，并不会对原有的User表中数据产生影响，从业务角度来说，我注销了一张银行卡，并不代表我不能登录系统了。
可能说的有点乱，其实我大致的意思就是说，作者大大可以不用考虑太多，既然用聚合根的概念了，那就完全按照领域驱动设计法则来就行，导航的问题就不再是问题了。
就像这个问题：“为了解决同一套实体类，不同的边界规则，例如两个同事都做了实体的 crud，公用一套规则可能存在冲突，同事A希望更新某导航属性，同事B不希望。”——如果说存在这样的分歧，首先我们要想的是不是设计上不合理，把有着不同业务领域的实体功能，集中到一个聚合根上了，是不是要把这个聚合根再分离出一个新的聚合根，对应一个新的数据表，而不是说从框架上从技术上来满足这种要求。

[2881099]

大佬有心了，回复这么多内容。
为了解决一个繁琐的问题而生，不一定和设计有关，和使用习惯有关，固定的规则。
等我有时间了，再消化消化