我正在开发一个项目，我有多个数据集，我想将它们合并到一个 .net api 中，我可以在其中使用实体框架返回数据。我仍处于开发的早期规划阶段，想检查一下我对整体设计的想法。
我有四个数据集，它们都来自互联网上的不同资源，但彼此相关。对于每种资源，数据在不同的时间以不同的方式出现。所以我的想法是为每个数据集提供一个加载器，该加载器将独立于其他数据集触发。
每个加载器会将其各自的数据加载到数据库中相应的表中，然后 API 将一起提供这些数据。
所以我的问题是，采用这种设计，我应该只拥有 api 中的实体吗？那么 api 迁移定义了加载器要加载到的数据库？这是一个有效的设计吗？对于这样的事情有最佳/常见的做法吗？
我试图避免在加载器和 API 之间重复实体，我知道你可以做一些事情，比如在项目之间共享类，但这看起来很混乱和令人费解。
我只用一个数据集尝试过这种设计，它有效，但不确定它是否是最好的。
我认为我们是否认为一种做法是最佳做法，应该取决于它在现实中是否带来任何缺点以及带来很多好处。众所周知，在sql查询中使用索引会带来性能提升，但是当表中数据行数很少时，全表搜索会有更好的性能。
以我的拙见，我对你的问题“我是否应该只拥有 api 中的实体”的回答是肯定的，这是基于“我已经尝试过仅使用单个数据集进行此设计并且它有效”。根据您的描述，您的应用程序正在尝试从外部不同资源获取数据，然后将它们存储到您的数据库中，并使用 EF core 从数据库查询，以便您的 API 代码可以处理（也许以某种方式组合数据）数据并让它们在某些地方使用。
如果是这样，我可以说为数据库中存储的数据创建实体是一个不错的选择，因为 EF core 总是这样工作，它为数据处理工作带来了便利。假设外部数据资源也为您的加载器提供稳定且长期支持的Web API来加载数据，那么我们就没有必要为这些资源创建实体，因为这次我们不需要处理数据，我们只需需要将所有加载的数据注入数据库。但是如果我们在加载数据时需要处理数据，例如添加一些验证/过滤/业务逻辑或其他东西，也许创建实体会带来额外的好处，但你没有提到这一点，所以我认为现在不需要。