C# 实体框架/外部同步体系结构_C#_.net_Entity Framework_Architecture

C# 实体框架/外部同步体系结构

c# .net entity-framework architecture

C# 实体框架/外部同步体系结构,c#,.net,entity-framework,architecture,C#,.net,Entity Framework,Architecture,我有一个应用程序，它使用Linq to对象查询本地数据存储（当前由XML文件支持）。应用程序中的另一个线程会定期向远程服务器查询更新的数据，如果存在，则会下载所有远程数据，对其进行反序列化，并在将新XML保存到磁盘之前用新的反序列化对象替换本地对象我决定用SQLite数据库替换XML文件，并打算使用实体框架与之交互。这促使我重新审视外部更改的应用方式，我决定只更新远程实体updated\u at属性比本地实体更新的数据（而不是当前替换整个数据集的方法）因此，我必须编写一个方法来下载外部更改，

我有一个应用程序，它使用Linq to对象查询本地数据存储（当前由XML文件支持）。应用程序中的另一个线程会定期向远程服务器查询更新的数据，如果存在，则会下载所有远程数据，对其进行反序列化，并在将新XML保存到磁盘之前用新的反序列化对象替换本地对象

我决定用SQLite数据库替换XML文件，并打算使用实体框架与之交互。这促使我重新审视外部更改的应用方式，我决定只更新远程实体

updated\u at

属性比本地实体更新的数据（而不是当前替换整个数据集的方法）

因此，我必须编写一个方法来下载外部更改，并将相关实体更新或插入SQLite数据库

我不明白的是，在架构方面，这种方法应该放在哪里。我（可能很天真）的想法是，一个通用的

UpdateFromRemoteObjects（List updateItems）

方法可以位于

DbContext

类中，并接受一个实体列表并更新相应的

DbSet

。但这感觉它可能与

DbContext

耦合得太紧密了。我应该使用存储库来提供一个层来实现这一点吗？还是另一种应用程序架构更合适？

许多人在设计组件时首先考虑：类有责任和合作者

首先考虑单一责任原则：一个有两个或两个以上责任的班级可能做得太多了。这就是您不将方法放在DbContext上的原因：更新内容是一项新的独特职责，所以为它创建一个类

我可以看到这个类做了两件事：QueryRemoteServerForChanges和UpdateLocalObjects

现在考虑它的合作者。它似乎需要两个实例：一个用于本地更改的DbContext实例，另一个用于访问远程数据的任何对象的实例

所以不是一个仓库不；而不是一层；但肯定是一个负有责任的类。

好吧，您在项目中已经有了一些查询。它们在代码中的位置是什么？