CODEWITHSUNDEEP
.netentity-frameworkentity-framework-core
Daniel García Rubio
Daniel García Rubio

Reputation: 622

Separate related entity framework models into different assemblies

Think of this tipical 1 to many relantionship:

public class Parent
{
    public int ID { get; set; }
    public virtual List<Child> Children { get; set; }
}

public class Child
{
    public int ID { get; set; }
    public int ParentID { get; set; }
    public virtual Parent ParentEntity { get; set; }
}

Now, what if these entities were related to totally diferent business layers, and we would like to declare them in different assemblies? As the parent entity needs to know about its children entity type, the parent's assembly would need to reference the child's assembly, and also the other way around, thus creating a circular reference.

Three questions come to my mind:

  1. Is there any non-hacky way to achieve this without creating the circular dependency between the assemblies?
  2. If the above is true, does it mean that the only supported way is to store all entities from a specific context in the same assembly? (If you have any separate sets of unrelated tables in a single database, why would they belong in the same database in the first place?)
  3. Could you argue that if they are database-related then they have to be necessarily business-related, therefore the entities belong together? I guess this assumption would depend on specific cases, but i'd like to hear some ideas about best practices on this subject if anyone has any strong feeling.

I know there are other questions in the site with similar titles, the only one actually refering to this same concept would be this one, but it might be quite outdated and I find both the question and its only answer quite vague.

Thanks in advance

Upvotes: 0

Views: 93

Answers (1)

D Stanley
D Stanley

Reputation: 152626

Is there any non-hacky way to achieve this without creating the circular dependency between the assemblies?

The proper way to do this is to use a third assembly that defines interfaces that each type references:

assembly3:

public interface IParent
{
    public int ID { get; set; }
    public List<IChild> Children { get; set; }
}

public interface IChild
{
    public int ID { get; set; }
    public int ParentID { get; set; }
    public IParent ParentEntity { get; set; }
}

Then reference the interface assembly in each of the assemblies. Whatever assembly brings the parent and child assemblies together then references all three assemblies.

Note that this may not be easy. It may mean more linking of the types manually rather then letting EF do it for you (since EF will want to use the concrete types rather than the interfaces). So at that point, you can decide if putting those types in separate assemblies is worth the trouble.

Could you argue that if they are database-related then they have to be necessarily business-related, therefore the entities belong together?

If they come from the same database and are joined as tightly coupled as you indicate, then yes I would say it's reasonable to put them in the same assembly. If some processes use one but not the other, then you might be able to optionally load the other type, but I'd need to know more about the specifics to make a complete recommendation (which would be outside the scope of this forum).

Upvotes: 1

Related Questions