Question

与EF建立关系和界面的最佳做法是什么？

我有一组现有的TDD类和接口，并要求使用Entity Framework Code First作为ORM。我有EF的经验，但对定义一对多和多对多关系的方式不满意。

我感到惊讶的是，这似乎没有更多的主要记录（假设我没有搜索不正确的术语）。

例如，我有：

public interface IBar {
      string BarValue { get; set; }
} 
public class Bar : IBar {
      string BarValue { get; set; }
} 


public interface IFoo {
      string FooValue { get; set; }
      ICollection<IBar> Bars { get; set; }
} 

public class Foo : IFoo {

      public Foo()
      {
          Bars = new List<Bar>();
      }
      public string FooValue { get; set; }
      public virtual ICollection<IBar> Bars { get; set; }
}

和

public interface IBar {
      string BarValue { get; set; }
      ICollection<IFoo> Foos { get; set; }
} 
public class Bar : IBar {
      public Bar()
      {
          Foos = new List<Foo>();
      }
      string BarValue { get; set; }
      public virtual ICollection<IFoo> Foos { get; set; }
} 


public interface IFoo {
      string FooValue { get; set; }
      ICollection<IBar> Bars { get; set; }
} 

public class Foo : IFoo {
      public Foo()
      {
           Bars = new List<Bar>();
      }
      public string FooValue { get; set; }
      public virtual ICollection<IBar> Bars { get; set; }
}

我不确定我是否在这里，你有什么想法吗？

Answer 1

我确定你已经知道了，因为它不在你的样本中所以我想我会提到它：不要忘记你的空构造函数。 EF Code首先使用这些来填充您的模型。

但是，您可能不希望它们暴露，因此请将它们保护而不是公开。 EF仍会看到受保护的构造函数，但它不会看到私有构造函数。

你的1对多关系看起来很好，虽然如果你想延迟加载工作它应该是虚拟的。

对于您的多对多，我的偏好是定义加入实体。我相信EF将为你提供幕后的连接表。但是，我喜欢保持导航属性的一面，以避免以后解析数据时可能出现的递归问题。

一旦我进入计算机，我将根据您的示例编辑一些示例。

好这里有一对多的例子......我必须跑步，但今晚会发布很多很多但是这个模式很容易扩展：

public interface IBar
{
    string barValue { get; }        // Values can sometimes be valuable in interfaces, see Foo's AddBar behavior.
    void SetValue(string value); // Interfaces work best describing behavior, not structure.
}
public class Bar : IBar
{
    public string barValue { get; private set; }

    protected Bar() : this("") { } // EF
    private Bar(string value)      // Private Constructor
    {
        barValue = value;
    }

    public static Bar Create(string value = "") // Factory
    {
        return new Bar(value);
    }
}


public interface IFoo
{
    void SetValue(string value);
    void AddBar(IBar bar);
}

public class Foo : IFoo
{
    // Our Properties... note that private set does not interfere with EF at all, and helps encapsulate.
    public string fooValue { get; private set; }
    public virtual ICollection<Bar> bars { get; private set; }

    // Constructor for EF, protected since we probably dont want to ever use it ourselves.
    protected Foo() : this("") { }

    // Our internal constructor, we will expose a factory for creating new instances (better control).
    private Foo(string value)
    {
        fooValue = value;
        bars = new List<Bar>();
    }

    // Our factory, great place to validate parameters, etc before even constructing the object.
    public static Foo Create(string value = "")
    {
        return new Foo(value);
    }

    // Methods for controling Foo's properties:
    public void SetValue(string value) { this.fooValue = value; }
    public void AddBar(IBar bar) { this.bars.Add(Bar.Create(bar.value)); }  // Leveraging Bar's factory
}

编辑：我最初使用它，因为示例有它，但我通常不会在界面中指定属性。通常，接口应被视为描述行为而非结构。实际上，实体框架工作将无法使用属性接口（公共虚拟ICollection条），因为它需要具有能够填充它的构造函数，当然接口没有构造函数。我已相应地更新了示例，并使界面更具行为性。今晚我还会添加许多例子。

好的，这是多对多的。一些亮点：我将Foo和Bar接口合并为一个，因为它们都具有相同的行为，这种方式更加通用。请注意，如何从foobar栏中直接遍历foo（你得到一个Id的列表），这可以防止遇到循环引用。您始终可以在任一侧添加一个或另一个的列表，并根据需要手动从存储库中填充它。

public interface IFooBar
{
    string value { get; }
    void SetValue(string value);
    void AddFooBar(IFooBar item);
}


public class Bar : IFooBar
{
    public string value { get; private set; }
    public virtual ICollection<FooBar> foos { get; private set; }

    protected Bar() : this("") { } 
    private Bar(string v) { 
        value = v;
        foos = new List<FooBar>();
    }

    public static Bar Create(string value = "") { return new Bar(value); }

    public void SetValue(string value) { this.value = value; }

    public void AddFooBar(IFooBar foo) { this.foos.Add(FooBar.Create(this.value, foo.value)); }
}

public class FooBar
{
    // assuming fooValue and barValue are the keys for Foo and Bar.
    public String fooValue { get; private set; }
    public String barValue { get; private set; }

    protected FooBar() { }
    private FooBar(String foo, String bar) {
        fooValue = foo;
        barValue = bar;
    }

    public static FooBar Create(String fooValue, String barValue) { return new FooBar(fooValue, barValue); }
}


public class Foo : IFooBar
{
    public string value { get; private set; }
    public virtual ICollection<FooBar> bars { get; private set; }

    protected Foo() : this("") { }

    private Foo(string v)
    {
        value = v;
        bars = new List<FooBar>();
    }

    public static Foo Create(string value = "") { return new Foo(value); }

    public void SetValue(string value) { this.value = value; }

    public void AddFooBar(IFooBar bar) { this.bars.Add(FooBar.Create(this.value, bar.value)); }
}

另外，请记住，没有使用命名约定，因此您必须装饰或添加流畅的地图（推荐），以便EF识别密钥并建立关系...如果他们使用EF的命名惯例这可以部分避免，但你仍然需要为FooBar的多部分键添加一个地图，例如：

public class FooBarMap: EntityTypeConfiguration<FooBar>
{
    public FooBarMap()
    {
        HasKey(k => new { k.barValue, k.fooValue });
    }
}

然后将其添加到您的上下文配置中。

希望有帮助......：）

关系，接口和实体框架

1 个答案: