RevEng: Make some APIs public (non-Internal)

[bricelam]

This exposes the entry point into the Reverse Engineer functionality (IReverseEngineerScaffolder); the contract for code generators (IModelCodeGenerator); and the service for selecting a code generator (IModelCodeGeneratorSelector).

It also adds extension methods for adding our design-time services to an IServiceCollection. (fixes #9339) You can use them like this:

var designTimeServiceCollection = new ServiceCollection()
    .AddEntityFrameworkDesignTimeServices()
    .AddDbContextDesignTimeServices(dbContext);
new SqlServerDesignTimeServices().ConfigureDesignTimeServices(designServiceCollection);

var designTimeServiceProvider = designTimeServiceCollection.BuildServiceProvider();

var migrationsScaffolder = designTimeServiceProvider.GetService<IMigrationsScaffolder>();
// migrationsScaffolder.ScaffoldMigration(...)
// migrationsScaffolder.RemoveMigration(...)

var reverseEngineerScaffolder = designTimeServiceProvider.GetService<IReverseEngineerScaffolder>();
// reverseEngineerScaffolder.ScaffoldModel(...)

This cleans up some other DI contracts too.

cc @dazinator @ErikEJ @tonysneed

[tonysneed]

@bricelam Have you thought about moving EntityEntryGraphIterator out of Internal? My framework depends on it

[bricelam]

@ajcvickers? (make EntityEntryGraphIterator public)

[ajcvickers]

@tonysneed Do you depend on EntityEntryGraphIterator or IEntityEntryGraphIterator?

[bricelam]

@tonysneed FYI, I imagined EntityFrameworkCore.Scaffolding.Handlebars would override IModelCodeGeneratorSelector since it's template-based and thus language-agnostic. Meanwhile, the VB and F# generators will override IModelCodeGenerator.

[tonysneed]

@ajcvickers I'm creating a new EntityEntryGraphIterator. The code looks like this:

public static void TraverseGraph(this DbContext context, object item,
    Action<EntityEntryGraphNode> callback)
{
    IStateManager stateManager = context.Entry(item).GetInfrastructure().StateManager;
    var node = new EntityEntryGraphNode(stateManager.GetOrCreateEntry(item), null, null);
    IEntityEntryGraphIterator graphIterator = new EntityEntryGraphIterator();
    var visited = new HashSet<int>();

    graphIterator.TraverseGraph(node, n =>
    {
        // Check visited
        if (visited.Contains(n.Entry.Entity.GetHashCode()))
            return false;

        // Execute callback
        callback(n);

        // Add visited
        visited.Add(n.Entry.Entity.GetHashCode());

        // Return true if node state is null
        return true;
    });
}

The reason for my own TraverseGraph method is that setting EntityState on TrackGraph halts recursion, and there are scenarios where I need to set the state but continue recursion.

[smitpatel]

Are these args converted to full path specification rather than relative paths?

[bricelam]

I wanted to do a bit verification in this area before merging.

[bricelam]

projectDir is. outputDir is as it was entered by the user

[bricelam]

Will normalize outputDir here.

[smitpatel]

Would we review these names before release?

[bricelam]

Yes. We'll cover in API review

[smitpatel]

    public class FakeAnnotationCodeGenerator : IAnnotationCodeGenerator

Could this override from base class?

---

Refers to: test/EFCore.Design.Tests/Scaffolding/Internal/ReverseEngineeringConfigurationTests.cs:52 in bdcc70b. [](commit_id = bdcc70b, deletion_comment = False)

[smitpatel]

public class ReverseEngineeringConfigurationTests

Should change name of this test file

---

Refers to: test/EFCore.Design.Tests/Scaffolding/Internal/ReverseEngineeringConfigurationTests.cs:16 in bdcc70b. [](commit_id = bdcc70b, deletion_comment = False)

[smitpatel]

[bricelam]

Agree the tests could use a bit more cleanup. I'll address as part of #9111

[ajcvickers]

@tonysneed For the not stopping on state set thing, we have an issue to fix this: #8226. It's good additional feedback that you would use this.

About the code you posted, is there a reason not to resolve IEntityEntryGraphIterator from the context D.I. rather than newing it up explicitly? For example, var graphIterator = context.GetService<IEntityEntryGraphIterator>();

(I'm asking these questions so as to determine if it is best just to make the service public or also the default implementation of the service. Generally we only make the default implementation public if it is expected that it act as a base class for customized implementations.)

[tonysneed]

For the not stopping on state set thing, we have an issue to fix this: #8226. It's good additional feedback that you would use this.

I'll comment over there for clarification.

About the code you posted, is there a reason not to resolve IEntityEntryGraphIterator from the context D.I. rather than newing it up explicitly? For example, var graphIterator = context.GetService<IEntityEntryGraphIterator>();

It didn't dawn on me I could use the context as a service locator. I'll refactor the code to do that. It would be nice to have IEntityEntryGraphIterator lifted out of the Internal namespace, but I don't think I have the need to extend EntityEntryGraphIterator.

[ajcvickers]

@tonysneed Thanks. Filed #10540 to track making IEntityEntryGraphIterator public.