Thanks Unai for starting this discussion. We will discuss this in more detail in an upcoming design meeting, but I wanted to take note of some initial considerations, some of which Arthur and I discussed today:
Cost of adding a new configuration type to the API surface vs. providing finer control
This is something we will have to discuss in greater detail: Personally, I like that the addition of AutoEntityTypeConfiguration makes it possible to maintain in your assembly existing EntityTypeConfiguration classes that are not going to be added automatically, and e.g. are instead added conditionally, are left for the configuration of a different context, or perhaps are only used for some testing. This makes it unnecessary (at least for now) to provide a different fine grained way to opt out of a specific configuration, e.g. ConfigurationRegistrar.Remove. On the other hand we are talking about adding new classes to the public surface. This is not only AutoEntityTypeConfiguration, but most likely also AutoComplexTypeConfiguration. We are usually very careful about adding only the necessary API because this usually helps keeping the stack easier to approach. In this case I am just not sure what the right tradeoff is.
Type discovery vs. configuration discovery
We need to make an explicit decision on whether this new mechanism can be used to discover not only type configurations but the types themselves.
AutoAdd overloads
We could probably simplify things a bit adding just one method to ConfigurationRegistrar: AutoAddFromAssembly, and have three overloads:
- AutoAddFromAssembly(Assembly assembly)
- AutoAddFromAssembly(string assemblyName)
- AutoAddFromAssembly(): this would automatically add the configurations from the current assembly, without requiring a call to this
Thanks,
Diego