实体做得太多了?

时间:2012-05-31 07:13:06

标签: c# linq-to-sql architecture dependencies

我有一个旧的谜题,所以我想我会与你分享,可能会得到正确的方向。 事实上,我们在数据库中的一些实体非常大(读取有很多属性),很少有业务逻辑使用所有实体属性,因此每次我需要考虑必须加载哪些属性才能使业务逻辑正常工作。非常假设的样本:

public class Product 
{
    public string Title {get;set;}
    public string Description {get;set;}

    public string RetailPrice {get;set;}
    public string SupplierId {get;set;}

    public Supplier Supplier { get;set;}

    // many other properties
}

public class ProductDiscountService
{
    public decimal Get(Product product)
    {
        // use only RetailPrice and Supplier code
        return discount;
    }
}

public class ProductDescriptionService 
{
    public string GetSearchResultHtml(Product product) 
    {
        // use only Title and Description
        return html;
    }
}

看起来我可以提取接口IDiscountProduct和ISearchResultProduct,将产品标记为实现这些接口,然后创建实现每个接口的较小DTO,但是现在看起来像是过度杀伤(至少我没有看到任何人对属性进行分组)使用接口)。

将数据库中的实体拆分为较小的实体也看起来不合理,因为所有这些属性都属于产品,我担心我会被迫使用很多连接来选择某些东西,如果我决定一些属性属于另一个实体,该移动将很难实现。

将特定方法的业务逻辑中使用的每个属性作为方法参数看起来也是不好的解决方案。

1 个答案:

答案 0 :(得分:1)

除非属性很大(读取长字符串和/或二进制文件),否则我只需加载它们。

以下几点适用于简单属性(例如标题)

  1. 没有额外的代码(只使用标题获得此产品,或只获得价格,等等)
  2. 产品实例始终完整,因此您可以传递它而不检查属性是否为空。
  3. 如果你不得不懒得加载其他一些属性,那么你需要花费更多的时间来加载它们。如果您有20个属性 - 这甚至不是一个大对象(再次,如果您的(假设的)描述属性的大小不是千字节)。
  4. 现在,如果您有相关对象(ProductSupplier) - 这应该是延迟加载的,imo,除非您知道将使用此属性。