实体框架核心和REST客户端 - 代码组织

Question

我正在构建一个包含三个项目的解决方案：

• .Data（包含实体框架核心类和Writer.cs）
• .ConsoleApp（启动项目，调用Writer.cs）
• .CloudTalker（网络服务引用和Fetcher.cs）

解决方案的目的是调用REST API，从API获取实体并使用Entity Framework Core将它们存储在数据库中。所有代码都运行正常，但我很肯定有办法改进架构。

从REST API获取客户并写入数据库的示例代码流：

{li} Program.cs .ConsoleApp实例化Writer.cs并调用方法WriteCustomers()。
1. WriteCustomers获取数据库中客户的最新修改日期
2. WriteCustomers在GetCustomers( latestModifiedDate )项目的Fetcher.cs中调用CloudTalker。此方法返回Customers的数组（REST API返回的类，而不是实体框架）。
3. WriteCustomers遍历数组，将REST对象转换为EF Core对象并将其放入_context.Customers。
4. Context.SaveChanges()将Customers存储在数据库中。

现在我的问题/征求意见：

• 我是否对问题进行了适当的分离？困扰我的是，CloudTalker需要了解EF类或EF类需要了解REST类。哪种方式更受欢迎？ CloudTalker.Fetcher.GetCustomers( lastModifiedDate )应该从EF类或REST类型返回对象吗？
• 我应该如何处理类的命名？现在我有两个Customer - REST类和EF类。不漂亮。
• 我还应该做些什么呢？

提前感谢您分享任何见解。

Answer 1

我觉得这应该属于codereview网站，但这就是我对架构的看法（我无视这可能是一个简单的项目，可以使用快速而肮脏的解决方案）

作者应该在一个单独的项目中，并且应该只知道EF和DB，提取器应该只知道REST以及如何调用远程服务。然后，您可以引入一个知道两个前砖的服务层，并调用fetcher获取数据，然后将数据传递给writer。

我认为没有业务逻辑，因此不需要单独的域项目。您的服务层可以直接在您的UI /控制台项目中。

对于命名，CustomerReadModel，CustomerWriteModel？

怎么样？

您似乎还需要从DB读取以获取最后修改日期，因此我建议您在数据库项目中的某个位置使用读者。