OOP/Repository模式:为不同的数据库访问子集创建过多的对象

本文关键字：访问 数据库 子集 对象 创建 Repository 模式 OOP | 更新日期: 2023-09-27 18:00:09

我正在将旧的VB6代码（是的，是的，VB6…）移植到C#。我正在重构代码，使其更加面向对象，除其他外，我正在实现访问数据库的存储库类。

现在，这些存储库类返回对象，而不是数据集。但我发现，有时我只返回对象可能包含的信息的子集。示例：我可以得到一个完整的文档列表，包括名称、文件路径、文件夹、创建者等，或者我可以得到只包含名称和文件夹的文档搜索结果。

对于这些子集情况，最佳实践是什么？我应该为这些只包含数据子集的数据库调用创建自定义对象吗？我应该返回只填充了部分字段的完整对象吗？还是应该只返回数据集？

OOP/Repository模式:为不同的数据库访问子集创建过多的对象

理想情况下，一切都应该尽可能集中。这可以通过为每个子集创建一个查询对象来实现。我认为您可以选择返回一些字段已填充或为null的对象，这取决于您的数据库是否允许这些特定字段为null。

因此，将规则和逻辑与存储库类集中在一起，这样每个对象都会根据这些规则和逻辑一致地返回。

为对象创建一个下属架构，这样它们就不会变得太复杂。我认为需要的是为存储库考虑每个对象一个实体。同样，创建自定义对象或DTO可能会产生不必要的代码和复杂性。为了完整性，请将填充了某些字段的对象和该子集中不需要的其他字段保持为空，这样，如果以后查询此信息，则可以报告特定实体不存在值的信息。

这里有一个简单的例子，尝试将POCO类与实体框架一起使用。

    public interface IRepository<TEntity, in TKey> where TEntity : class
{
   TEntity Get(TKey id);
}
public class SomeRepo1 : IRepository
{
  private readonly FileDbContext someDbContext;
   public FileRepository(FileDbContext dbContext)
   {
      someDbContext = dbContext;
   }
   public File Get(string id)
   {
     return someDbContext.Files.ToList();
   }
}

可用于文件的POCO类示例：

public class File
{
   public int Id { get; set; }
   public string FileName { get; set; }
}
 public class Folder
   {
     public List<File> Files { get; set; }
   }

更多详细信息请点击此处：https://msdn.microsoft.com/en-us/library/ff649690.aspx

希望这能有所帮助！

但我发现，有时我只返回对象可能包含的信息的子集。

您刚刚混淆了对象模型和持久性模型。

您知道，对象模型并不关心存储是如何实现的。具体来说，如果对象模型后面有一个数据库，并且您有包含一些数据的表，那么您可以随心所欲地将数据库映射到对象模型。例如，使用一个聪明的对象关系映射器，您可以将一个表拆分为两个类，或者在同一个表中保留多个类。

因此，从存储的角度来看，看起来像"子集"的东西，从对象模型的角度来看可能不是"子集"。

一个特定于Entity Framework 6的示例解决方案涉及所谓的表拆分，它允许您将模型类拆分为两个类，一个类具有始终加载的核心属性，另一个类带有辅助属性，仅当您引用核心类的虚拟属性时才延迟加载。

示例教程：http://www.c-sharpcorner.com/UploadFile/ff2f08/table-splitting-in-entity-framework-6-code-first-approach/

（只需提及，相反，其中两个物理表映射到oe模型类被称为实体拆分）

相关文章：