Skip to content
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

Make it easy to create a provider configured ModelBuilder #3529

Closed
anpete opened this issue Oct 23, 2015 · 2 comments
Closed

Make it easy to create a provider configured ModelBuilder #3529

anpete opened this issue Oct 23, 2015 · 2 comments
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-enhancement
Milestone

Comments

@anpete
Copy link
Contributor

anpete commented Oct 23, 2015

One scenario we want to support is external model creation via ModelBuilder. However, it is currently difficult to get a ModelBuilder instance that has been configured with a provider specific convention set.

cc @sebastienros

@rowanmiller
Copy link
Contributor

Discussed in triage and decided we should have ModelBuilder factories so that folks don't need to worry about conventions etc. (especially since conventions are 'internal' for the first release).

Folks can just create one up like this (note this is a static Create() method on the factory rather than a default ctor to get a factory since having a default ctor doesn't play well with DI):

var builder = SqlServerModelBuilderFactory.Create()

Alternatively, if you want it to get all it's services from DI then we'll register one that you can just resolve... then you will get the same logger, etc. that is registered in DI (plus if you have overridden the type mapper etc. then you will also get those services).

sp.AddEntityFramework()
  .AddSqlCompact()
  .AddNpgSql()
  .AddSqlServer();

var builder = sp.GetService<ISqlServerModelBuilderFactory>().Create();

@rowanmiller
Copy link
Contributor

BTW when we do this we should consider making convention sets internal too. I know providers might use them... but that is ok, it just means they aren't guaranteed to be stable between releases.

@AndriySvyryd AndriySvyryd modified the milestones: 7.0.0-rc2, 7.0.0 Dec 8, 2015
@AndriySvyryd AndriySvyryd removed their assignment Apr 1, 2016
@ajcvickers ajcvickers modified the milestones: 1.0.0-rc2, 1.0.0 Oct 15, 2022
@ajcvickers ajcvickers added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label Oct 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-enhancement
Projects
None yet
Development

No branches or pull requests

4 participants