I use it on a project at work. I am constantly trying to explain why using a single DBContext for the entire application is a terrible idea. I am met with fluoride stares
It can be very convenient if you have the luxury to start from scratch.
However, it's mostly shilled by architecture astronauts and those "people" will find a way to misuse any tool.
Yes.
All performance issues in a python project I help maintain come from shitty misuse of the Django ORM. That also includes most logical errors. Not to mention, you're pretty limited when doing anything non-trivial.
Also .NET is a meme, wtf are you doing on IQfy OP? You can't be having a job here.
I took off early today for the holidays, felt like shitposting.
It does speed up getting started a lot and doing big queries where you join 5 tables together.
Can be annoying for performance or using db specific features. Does ef core have bulk inserts yet?
It does speed up getting started a lot and doing big queries where you join 5 tables together.
Can be annoying for performance or using db specific features. Does ef core have bulk inserts yet?
my company literally forced us to use dapper because ef queries were destroying the db
if i'm honest. i fell like that's more on the garbage architecture than ef's fault but oh well
>Is ORM a meme
If you have to ask this, it's because you've never tried writing anything that uses SQL in any remotely complex way. Once you do, you're presented with 3 options >1. use an ORM >2. write your own code to generate queries from data and turn results into data (spoiler: you just made your own ORM) >3. fill your application with gigantic piles of unmaintainable SQL every time you need to read/write to the database, even minor schema changes will make you want to kys
Like anything else, there are good and bad ORMs, with good and bad ways to use them. If you know what you're doing and use a decent ORM (specifically one that gives the freedom to write your own queries when you need to, because you will need to, while still doing most of the mapping for you) you'll be doing yourself a huge favor.
1, i can just write classes and the db schema gets automatically created based on them
2, i can do migrations just by saying "add-migration" -> "update-database" instead of writing fualty migration scripts by hand. i can also jump from any migration version to any migration version with just a single line of command
3, i can also change the db behind the code by just changing one line. for example:
//change this
options.UseSqlServer();
//to this
options.UseSqlLite();
4, i can query the database just by writing normal code like this:
var result = ctx.Users.Where(x => x.age >= 18)
.Select(x => x.name)
.Order();
5, i dont have to care about sqlinjection to orm takes care of it
The only reason why i would ever decide not to use an ORM is if i needed all the perf i can get.
Most people shitting on ORM's either never used one or used shitty the ones
>The only reason why i would ever decide not to use an ORM is if i needed all the perf i can get
Hey smoothbrain, 100% of ORMs have a way to bypass the ORM syntax and use raw SQL, if you _need_ that extra oomf/customization.
Dapper and EF’s gap has shrank significantly. I imagine by .NET 9 or 10 it won’t be a topic for discussion. We still use Dapper but recently investigated EF and it’s gotten actually usable.
I use it on a project at work. I am constantly trying to explain why using a single DBContext for the entire application is a terrible idea. I am met with fluoride stares
why?
tracking overhead
It can be very convenient if you have the luxury to start from scratch.
However, it's mostly shilled by architecture astronauts and those "people" will find a way to misuse any tool.
Yes.
All performance issues in a python project I help maintain come from shitty misuse of the Django ORM. That also includes most logical errors. Not to mention, you're pretty limited when doing anything non-trivial.
Also .NET is a meme, wtf are you doing on IQfy OP? You can't be having a job here.
I took off early today for the holidays, felt like shitposting.
pic related
Nice. For a long time bulk needed some ef core plus or whatever.
EF core plus still lists bulk as a paid feature. Is it old news?
https://github.com/borisdj/EFCore.BulkExtensions
>paying for a component of a free product
what the FRICK
Thats most advertised ef core extension for you. Most free but then the best features paid.
Ah makes sense. Didn't know about that extension
It does speed up getting started a lot and doing big queries where you join 5 tables together.
Can be annoying for performance or using db specific features. Does ef core have bulk inserts yet?
my company literally forced us to use dapper because ef queries were destroying the db
if i'm honest. i fell like that's more on the garbage architecture than ef's fault but oh well
>Is ORM a meme
If you have to ask this, it's because you've never tried writing anything that uses SQL in any remotely complex way. Once you do, you're presented with 3 options
>1. use an ORM
>2. write your own code to generate queries from data and turn results into data (spoiler: you just made your own ORM)
>3. fill your application with gigantic piles of unmaintainable SQL every time you need to read/write to the database, even minor schema changes will make you want to kys
Like anything else, there are good and bad ORMs, with good and bad ways to use them. If you know what you're doing and use a decent ORM (specifically one that gives the freedom to write your own queries when you need to, because you will need to, while still doing most of the mapping for you) you'll be doing yourself a huge favor.
>in any remote complex way
stored procedures are your friend
Worst thing ever for maintainability, versioning and editing.
My company operates on stored procedures. This is the worst way of doing things
I've seen bad SQL spaghetti and bad ORM spaghetti. The important thing is to have a clear, consistent design.
>Is ORM a meme?
1, i can just write classes and the db schema gets automatically created based on them
2, i can do migrations just by saying "add-migration" -> "update-database" instead of writing fualty migration scripts by hand. i can also jump from any migration version to any migration version with just a single line of command
3, i can also change the db behind the code by just changing one line. for example:
//change this
options.UseSqlServer();
//to this
options.UseSqlLite();
4, i can query the database just by writing normal code like this:
var result = ctx.Users.Where(x => x.age >= 18)
.Select(x => x.name)
.Order();
5, i dont have to care about sqlinjection to orm takes care of it
The only reason why i would ever decide not to use an ORM is if i needed all the perf i can get.
Most people shitting on ORM's either never used one or used shitty the ones
>The only reason why i would ever decide not to use an ORM is if i needed all the perf i can get
Hey smoothbrain, 100% of ORMs have a way to bypass the ORM syntax and use raw SQL, if you _need_ that extra oomf/customization.
I forgot about that yeah. You sure feel smart right now
EFCore RawSql is still slower than Dapper.
Dapper and EF’s gap has shrank significantly. I imagine by .NET 9 or 10 it won’t be a topic for discussion. We still use Dapper but recently investigated EF and it’s gotten actually usable.
We use dbt instead. Not perfect but makes more sense than doing everything in Python Pandas. THOT