dotnet
Allow to specify dependencies in IEntityTypeConfiguration
IEnumerable<IEntityTypeConfiguration> Predecessors {get;}
This will allow ApplyConfigurationsFromAssembly to apply them in correct order, see https://github.com/dotnet/efcore/issues/21304
It's really nice to have IEntityConfiguration co-located with the entity in question so you don't have to hunt for it, but once I started dealing with some shadow properties I ran into this.
Might make sense to have the inverse attribute from the one proposed, It would be an attribute that can be put on a base class saying in effect that derived classes all depend on the base class. That way the design decision can be made by the base class rather than by an unknown number of derived classes.
@sjb-sjb If the derived classes are unknown then how would they be specified as successors in the base class configuration? Generally, there are fewer predecessors than successors and they are more practical to specify.
That said, if a compelling use case is presented, we could add both ways of specifying dependencies.
Hi @AndriySvyryd the descendants would not be specified, the ordering relation would apply to all derived entity classes’ configurations in the assembly. In other words we would only specify DescendantsAreSuccessors = true in the base class’s IEntityTypeConfiguration. The value is you do not have to list the derived classes explicitly or know what they are in advance. It’s logical since typically the design of the base class should not require knowing what the derived classes are.
Ideally there would be a way to get this to work across assemblies based on the dependencies specified in the build.
I said “attribute” in my comment above but I see we are actually talking about interface properties.
@sjb-sjb This is a more general feature that would allow specifying arbitrary ordering constraints, not just base/derived, but the user would need to specify the dependency explicitly and statically. Wouldn't this be enough for your scenario?
Note I agree with the proposed feature, I’m suggesting adding an additional element.
I think it logically makes sense for the base class to state a requirement that it be configured first, rather than making this optimal for the descendants. There are likely reasons from the base class’s point of view why it needs to be configured first and therefore it makes sense for the base class to be able to configure itself first without allowing the descendants to break the ordering. Otherwise the situation is a bit analogous to having the derived classes decide whether or not to call the base constructor first.
Indeed arguably another approach would be to simply say that if Configure is defined for a class then it will be executed before Configure of derived classes. Since you have to analyze the relationships anyway and sort them, I don’t think there is much efficiency gain by omitting this feature. I don’t think that derived classes should be able to force their configuration to go ahead of base configuration.
Sure, we can make the closest base class configuration a predecessor by default and if the opposite is specified explicitly then it will override the default.
By “closest base class” do you mean the closest base class that has an EntityTypeConfiguration attribute? I guess if there is no attribute then there is no Configure function to call. Is there a war to do this with Fluent as well?
By “closest base class” do you mean the closest base class that has an EntityTypeConfiguration attribute? I guess if there is no attribute then there is no Configure function to call.
Yes
Is there a war to do this with Fluent as well?
Not sure what you mean, EntityTypeConfiguration classes use Fluent API.
So, if there is a chain of base classes then I guess they would be executed in the “correct” base-first order unless there were a defeating / overriding edge added sommelier along the chain….
This all sounds good to me.
Sent from my iPhone .