It just so happened that in our old ASP.NET MVC project, the database table models were stored with identical names, i.e. in lower case, with underscores, etc., and DTO is already in the standard .NET naming .
This was done for a number of reasons. The main ones are: the scope of the model is clearly defined; convenience when building linq queries, when the names of tables and columns can be easily transferred from, for example, sql query.
Unfortunately, in .NET Core applications, EDMX is no longer supported, and the CLI team has a rather poor set of features. So we had to go for a little trick.
Perhaps, in release 1.2 they will add this option, but so far it is not there, so it is necessary to go to extreme, temporary measures.
To begin with, we will create a project that will contain all our models. This will be a console .NET Core application.
Why Console Application, and not Class library, you ask. The whole point is Entity Framework supports .NET Core CLI commands only of these frameworks:
And Class library uses netstandard, not destiny. In any case, the created console .NET Core application can be added to the ASP.NET Core project.
I will not beat around the bush; I’m writing to write out what this file is responsible for. I think there’s no special meaning, we haven’t gathered here for that.
{ "version": "1.0.0-*", "buildOptions": { "debugType": "portable", "emitEntryPoint": true }, "dependencies": { "Microsoft.NETCore.App": { "type": "platform", "version": "1.0.0" }, "Microsoft.EntityFrameworkCore.SqlServer": "1.0.0", "Microsoft.EntityFrameworkCore.SqlServer.Design": "1.0.0", "Microsoft.EntityFrameworkCore.Design": "1.0.0-preview2-final" }, "frameworks": { "netcoreapp1.0": { "imports": "dnxcore50" } }, "tools": { "Microsoft.EntityFrameworkCore.Tools": "1.0.0-preview2-final" } }
When creating our Program.cs it looks like this:
namespace DomainModels { public class Program { public static void Main(string[] args) { } } }
We will expand it. So, let's move on to a little research. Having a little rummaged in EF source code on GitHub, I found the use of the dependency class CandidateNamingService for scaffolding. Having run a quick glance through the code, I realized that he was responsible for transforming the name of the database entity into the format of the .NET naming standard. And all we have to do is override the GenerateCandidateIdentifier function so that it returns the original name of the entity.
Let's extend our code to this option:
namespace DomainModels { public class Program { public static void Main(string[] args) { } } public class MyCandidateNamingService : CandidateNamingService { public override string GenerateCandidateIdentifier(string original) { return original; } } }
Of course, you can put any logic you like in GenerateCandidateIdentifier .
Now it is necessary to introduce dependency using AddSingleton. But where and how to do it? Since CandidateNamingService is related to design-time services, we need to define the ConfigureDesignTimeServices method in the Program class:
namespace DomainModels { public class Program { public static void Main(string[] args) { } public void ConfigureDesignTimeServices(IServiceCollection services) { services.AddSingleton<CandidateNamingService, MyCandidateNamingService>(); } } public class MyCandidateNamingService : CandidateNamingService { public override string GenerateCandidateIdentifier(string original) { return original; } } }
Done! It's time to generate models.
Here I will not go into details, all the features of the CLI are painted here , and we consider the final version of the commands without various settings:
dotnet restore dotnet run dotnet ef dbcontext scaffold '---' Microsoft.EntityFrameworkCore.SqlServer
That's all you need to set up and generate models. By the way, for a more convenient scaffolding, I wrote a small PowerShell script , suddenly someone will come in handy.
Source: https://habr.com/ru/post/314624/