✅ Why the need to create a database using EF core and not do it manually using SQL
Hello guys, I'm currently learning the EF core so that I can connect with my database using SQL Server. I have a question. I noticed that if we want to create a database using EF core, we need to create a dbContext, a specific instance, like a Student class with its properties etc. My question is, is all that required? Can't we not just use SQL statement to create all that using SQL Server? Isn't it easier? Or there is use cases of when we absolutely need to use C# code?
54 Replies
You need a way to create the queries somehow
When you do code first like that, EF ultimately generates SQL code to create the database and tables for you
SQL is always how you'll communicate with the database
If you don't have a
Person with a name, you can't have a DbSet<Person> so you can't reference the tableEF is a library provided to make working with it from C# easier
And you can't query by name with
.Where(p => p.Name == name)the entire point of ORMs like EF Core is so you can interact with the database using type-safe C# code, there is nothing stopping you from using raw SQL or something more minimal like dapper
Unknown User•2d ago
Message Not Public
Sign In & Join Server To View
ah, we can't create the queries without the dbContext? (I haven't try it yet)
You can just rawdog SQL, but then there's no point using EF and you should just go with Dapper
you can create a query however you want
you can also go with Linq2DB if you want type-safe SQL without the change tracking and hand-holding that EF has
done
Unknown User•2d ago
Message Not Public
Sign In & Join Server To View
EF also has methods like
context.Database.SqlQuery() that allow you to write your own SQL and send it to the databaseTrue
Unknown User•2d ago
Message Not Public
Sign In & Join Server To View
if you really want you can create your database with raw SQL and scaffold a dbcontext from there, but if it's a new application then taking advantage of EF migrations is usually more convenient
Unknown User•2d ago
Message Not Public
Sign In & Join Server To View
EF is nice for migrations. Just run the migration to set up the database in a new environment. Boom. Now you don't have to go through the pain of manually running SQL commands
I often saw the term "Code first approach"; this is when we use the dbContext to create the database schema ?
yes
yes
yes
the opposite would be database first, using the database schema to create the dbcontext
ok ok starts to make sense, will continue to read 2sec
code first you basically just change your C# models then tell EF "figure out what i changed and generate SQL to change the schema the same way"
yeah, this is where migrations and all came into play?
That is so helpful.
until you have to write migrations by hand :when:
you can also ask efcore to generate a sql script for you
which you don't 99% of the time, but i happen to be doing that right now because EF doesn't support columnstore tables directly
hmm the thing is, in order to create queries, we need to have a context?
yeah i like EF because 99% of the time i can do things the EF way but then it also gives you escape hatches for the 1%
ye
irrespective of whether we are using code first or we are scaffolding ?
ye
When you scaffold, EF will generate the context from the database schema
And all the models
With code-first, it's the reverse
You create models and context, and EF creates he db schema
yeah I see
with EF you always need a dbcontext, that's just how you use EF
that object represents the database in your code
it's worth noting that the whole point of using EF is to create queries and map their results for you. it's not so much that a context is required to write queries, it's that you're using EF to write queries for you
i've been using EF primarily with linq2db on top for things EF doesn't support like merge queries
even the term "writing queries" is a little ambiguous here because (most of the time) you won't be writing SQL, you'll be writing LINQ that EF turns into SQL
i need to give linq2db another look
Yeah, it's more like translating queries than writing
Yeah I see, so to recap:
In order to use EF Core, we need a dbContext, irrespective of whether we use the code first approach (code first approach is where we create the model and everything related, its context, properties, etc using code) or database first approach (use sql statements to create database directly in sql server). The thing is when we use the database first approach, we might introduce typos, which we don't want and this may be avoided. Now if we use the database first approach, we still need a context to be used, their is where we need to scaffold the database so that the model/classes are created automatically for us and we can use that to write our LINQ expressions.
can anyone just confirm if I have correctly understood based on this summary pls
pretty much
Yeah
noted, thanks, I learn a lot right now, really appreciate all the responses 👍
by the way linq2db is same thing as LINQ?
no
it's a different ORM
GitHub
GitHub - linq2db/linq2db: Linq to database provider.
Linq to database provider. Contribute to linq2db/linq2db development by creating an account on GitHub.
but it can be used alongside EF if you need to make queries that EF doesn't support, using EF's model
oh ok I see
Linq2db can even be kinda bolted on top of EF, where it basically just adds the missing bits
linq2db doesn't have migrations or change tracking built in, and the queries you write are much closer to raw SQL (but still type-safe C#) than in EF which is more like your typical C# LINQ
yep I see, will just get started with EF core for now
Thanks guys ! 💯