如何使用 EF Core 6 和值对象实现 Web API 项目字段级权限

Question

试图找出可能的实施，我感到非常沮丧。

根据DDD和CQS概念，我的应用程序的写入side 使用了用EF Core实现的各种聚合物和相关存储库。

在读取侧面上，我想使用在某些情况下链接相关数据的查询。这可能只是ID的分辨率（即进行最后一个编辑的用户名称）或出于性能原因列表（即一个人的地址簿）。

因此，返回的对象（getPersondto）的结构在内，包括分辨率或子女是写对象（人）的不同。我将价值对象用作实体中所有属性的类型，以将验证保持在一个位置（始终有效的对象）。

我的问题在读取方面。从get请求返回的资源表示形式是JSON。与请求主题相关的权限决定是否包含在JSON中的字段。

我的想法是，我使用EF Core返回查询对象和一个权限对象，该对象保留该对象的字段权限（用户）。如果主题已对某个字段的阅读许可，则将映射到DTO。 DTO使用可选＆lt; t＆gt;和一个自定义jsonConverter，如图所示在这里。结果，所有可选＆lt; t＆gt;未设置的字段将不包括在JSON响应中，但它保留了设置为null的字段。

我使用RAW SQL在EF Core中编写查询，因为我没有使用LINQ编写更多复杂的查询。 EF核心需要无钥匙实体来进行原始SQL查询。我希望EF Core使用为写侧创建的转换器将读取字段转换为值对象。

但是无钥匙实体不能成为关系的主要端，因此他们不能拥有拥有的实体。作为各种github 问题RAW SQL查询。据说

在EF中，每个EntityType映射到一个数据库对象。相同的数据库 对象可以用于多个实体类型，但您无法指定 数据库对象实现对象图。

如果我正确理解，也无法通过视图或存储过程实现此目的。在我看来，也无法定义使用现有DBSET对象的另一个完全连接的GetPerson对象。

如何实现？什么是替代方案？

我能想到

a）使用具有原始类型的原始SQL结果的平面对象，然后使用它映射到DTO。用原始创建对象图的副作用是创建值对象从数据库验证此数据。因此，我要么必须信任数据库，要么需要调用手动价值对象中公开的验证方法。

b）忘记EF核心，使用ado.net。返回对象是ADO.NET记录。考虑到记录场的权限，将映射到DTO。这很简单，开销较少，但需要框架的另一部分。

还有其他选择吗？考虑到字段权限，您如何解决返回组合对象的返回？

Answer 1

EF6核心不支持持续的值对象，这是EF7中计划的功能： https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-new/ef-core-7.0/plan#value-objects

诸如EF之类的ORM的目的是允许程序员通过对象而不是基于文本的语言（例如SQL）操纵RDBM。此对象模型不是业务模型，而是RDBMS概念的符号（class = table，row = object，column =属性，...）。对于微不足道的应用程序，您可能会混淆模型，但是您很快就会发现自己有限，因为业务模型的限制与数据库架构不同。对于较大的应用程序，您编写一个持久性模型，该模型由与数据库结构匹配的DPO组成，并将该模型转换为基础结构层中的其他模型。将您的域模型从持久性模型中脱在一起，可以在应用程序中更灵活，并将域对象重新覆盖为多理型模型，从而限制了独立用例的副作用。

这里的一个示例是将标准化的rdbms带有表格，包括替代键，这些替代键隐藏在存储库完成的投影过程中的域模型。这使您的数据库可以解决关系映射的复杂性，同时在域层中重新整理价值对象。

对于查询，您不应使用GetPerson模型发布您的实体。域层的目的是保护您的应用程序免于违反任何业务规则。查询应用程序状态时，您不会修改应用程序的状态，也不能违反任何规则。域模型仅对状态更改用例有用。因此，处理查询时，您应该直接从DPO绘制DTO。您将保存性能，并允许您的DTO通过诸如AutoMapper之类的库将/过滤器/分页功能直接分类/过滤/分页功能，只要该投影以此库的翻译容量为单位。同样，您的业务规则实施将不会受到大型且复杂的查询模型的影响，这是CQS体系结构的初始目的。

无论您是通过EF等ORM操纵数据库，还是直接在Ado.net级别操纵的RAW SQL查询是基础结构层的实现细节。选择取决于您是否认为自己可以编写比ORM编写“更好”的查询，“更好”作为主观问题，取决于您的项目限制。

---

更新1 ：关于使用可选＆lt; t＆gt;映射到您的DTO，EF Core的能力有限地将关系数据映射到不简单地表示数据库架构的模型中。这是通过设计，您不应强迫EF尝试直接将数据直接恢复到DTO中。使用单个模型添加了您的API接口和数据库持久性方案之间的依从性。每次更新持久性架构和反之亦然，您都会冒着界面破坏变化的风险。您应该有两个不同的模型，可以使演示文稿与持久性解脱。

无论您是使用EF Core还是ADO.NET读取数据库都不会在概念上发生太大变化。在这两种情况下，您都将数据库信息读取为存储器模型，然后将该模型转换为DTO。不同之处在于，此内存模型是基于OOP（EF + DPO模型）还是键值表（ADO.NET + DATAROW）。

使用EF核心的优点是，由于生成查询并且始终为您逃脱了值，因此它不太容易出现SQL注入。同样，持久性模型可以通过映射库（例如自动应用程序）转换为DTO。自动应用程序使翻译更容易，更便宜。此外，它可以将某些翻译投射到关系模型中。

如果您设法将您的安全性建模到地图配置文件中，则数据库只能选择DTO中数据博览会所需的列。换句话说，如果不允许用户公开dto.name，则数据库将不包括table.name纳入选择语句。但是，这并不总是可以做到的，但是这样做比在SQL中编写“聪明”查询要容易得多。

但是，EF的一个缺点是它比ado.net慢。

如果您确实需要将查询分为两个阶段转换（映射和安全性），则应将安全层更接近数据库，除非翻译逻辑要求该数据相应地映射。

Answer 2

这是一个主观和最佳实践问题，但是我会回答我如何解决类似问题 - 鉴于我实际上正确理解了您的问题。

只要您使用导航属性完全映射了数据库模型，就可以生成非常复杂的查询而不诉诸于原始查询。

    var dto = await context.Persons
        .Where(p => p.Id == id)
        .Select(p => new GetPersonDTO
        {
            Id = p.Id,
            InternallyVerifiedField = !p.UsersWithAccess.Contains(currentUser) ? new Optional<int>(p.InternallyVerifiedField) : new Optional<int>(),
            ExternallyVerifiedField = permissions.Contains(nameof(GetPersonDTO.ExternallyVerifiedField)) ? new Optional<int>(p.ExternallyVerifiedField) : new Optional<int>()
        })
        .SingleOrDefaultAsync();

在此示例中，internallyverified field将取决于某些查询内联，externallifiedfield将取决于某些外部权限对象。 externallified Field的好处是，如果用户没有许可，则可以在到达SQL Server之前从表达式中进行优化。

如果要从完全连接的对象构建DTO对象，它仍然可以在类似于

    var dto = await context.Persons
        .Where(p => p.Id == id)
        .Select(p => new
        {
            permissions = new GetPersonDTOPermissions
            {
                FieldA = context.Permissions.Where(...)
            },
            person = p
        })
        .SingleOrDefaultAsync();

此解决方案的一个查询中完成，您需要从Graph对象Person给定结果<代码>权限，只要您以上下文开始，然后使用 添加 将其添加。