-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow to specify dependencies in IEntityTypeConfiguration #22035
Comments
It's really nice to have |
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? 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? |
Yes
Not sure what you mean, |
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
.
|
This will allow
ApplyConfigurationsFromAssembly
to apply them in correct order, see #21304Also add a
bool
parameter toApplyConfigurationsFromAssembly
that, when set totrue
, will make the closest base class configuration a predecessor by default and if the opposite is specified explicitly then it will override the default.The text was updated successfully, but these errors were encountered: