C# 实体框架/ASP.NET REST 和模型设计模式或解决方案架构答案

【问题标题】：C# Entity Framework / ASP.NET REST and Models Design Pattern or Solution ArchitectureC# 实体框架/ASP.NET REST 和模型设计模式或解决方案架构
【发布时间】：2020-05-09 16:53:32
【问题描述】：

我正在开发一个 .NET 4.0 Windows 服务。此 Windows 服务（必须是 .NET 4.0）通过 REST 与 ASP.NET Web API .NET 4.5 进行数据交换。数据存储在 SQL Server 中。我决定通过 Entity Framework 6 (.NET 4.5) 进行数据访问。现在我有一个关于实体框架和 .NET Windows 服务所需的模型的问题。如果我使用 Code-First，它可以工作 -> 我可以从 Windows 服务项目和实体框架项目中引用模型。当我选择数据库优先时，实体框架根据数据库生成模型类，我没有可以在 .NET 4.0 中引用的带有模型类的专用 .NET 4.0 程序集Windows 服务项目。我可以创建一个额外的 .NET 4.0 程序集并在其中再次定义模型类，但这非常乏味且耗时。

下图中的每个正方形都是一个单独的项目。在第二个插图中-> .NET 4.0 Windows 服务对模型一无所知，因此我无法将 JSON 反序列化为对象。

有什么提示吗？

【问题讨论】：

即使在代码优先工作时，您也希望在服务层和数据层之间有一个 DTO 层。无论如何，首先远离 db。这是一个死胡同。
Entity Framework 生成基于数据库的模型类 - 在生成这些模型类的任何地方，您都可以在您的服务中引用此程序集。但是站在 Gert 一边，先忘记数据库。
试试这个帖子：stackoverflow.com/questions/23648832/…

标签： c# .net entity-framework design-patterns

【解决方案1】：

数据库实体不应暴露在您的数据访问层之外（在这种情况下）。您可以尝试拥有一个单独的层域/核心，您可以在其中保存您的实体。

服务层介绍可以让您在由数据库首先生成的 DB 实体和您可能希望通过 Web API 公开的 DTO 之间建立映射。

Windows 服务端也应该有相同的 DTO。但是，就像对 OP 的评论所说，每次添加/删除新字段的数据库迁移时，您都需要在这些合同 (DTO) 中进行手动更改。

代码优先是其他答案/cmets 中刚刚提到的方法！

【讨论】：

【解决方案2】：

代码优先为您提供了实现所需目标的灵活性，这就是为什么它比 DB 优先更可取的原因。

代码优先允许您将模型放在您想要的任何地方，DB 首先将使用实体框架上下文定义它们。如果您确实想将它们分开，那么您将不得不投入额外的工作再次重新创建它们，这正是您想要避免的。没有其他方法可以解决这个问题。

【讨论】：