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

Question

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

我决定用SQLite数据库替换XML文件，我打算使用实体框架与它进行交互。这促使我重新审视应用外部更改的方式，并且我已经决定只更新远程实体updated_at属性比本地实体更新的数据（而不是更新整个数据的当前方法设置）

所以我必须编写一个方法来下载外部更改并更新或插入相关实体到SQLite数据库中。

我不明白的是，在架构方面，这个方法应该坐在哪里。我的（可能天真的）想法是，通用的UpdateFromRemoteObjects<T>(List<T> updatedItems)方法可以位于DbContext类中，并且会接受实体列表并更新相应的DbSet。但是这感觉就像它可能与DbContext太紧密耦合。我应该使用存储库来提供一个图层来实现这一点吗？还是另一种应用程序架构更合适？ 类有责任和合作者

首先考虑单一职责原则：

Answer 1

很多人在设计组件时开始CRC有两个或更多的责任一类可能是做得太多。这是你不把这个方法放在DbContext上的原因：这个更新的东西是一个新的独特的责任，所以为它创建一个类。

我可以看到这个类做2件事：QueryRemoteServerForChanges和UpdateLocalObjects。

现在考虑它的合作者。它似乎需要两个：本地更改的DbContext实例，以及任何可以访问远程数据的实例。

所以不是仓库没有;而不是一层;但绝对是一个负责任的班级。