"C# with net core is more efficient performance-wise" might be but not that much in case of standard REST/CRUD. Worked with both, not noticeable to the end user, never tested the actual milliseconds and once browsed pages like link I'm quite sure opposite is true. And I mainly focus on Cloud and multiple DB access as those are usually most use cases.
However it's awful in many ways with it's horrible EF Core and it's disgusting approach of instantiating services, controllers and so. Creating and using Singletons because of the way it's dependency injection works was so horrible for me that I just gave up. And reason I tried it is because - Why would I create new controller, services, whatever, each request? Does that sound efficient for you? To me no and sorry but I really don't buy Microsoft way of doing things. It's not PHP, it's not interpreted language and I don't need that "singletons are bad" excuse. So in the end as developer who did both I would never go back to C# even if it's more performant in these cases.
Born in 1979, engineer, doctorate in 2008, I've started my working activity both as a researcher and as a freelance in the industrial automation field.
Born in 1979, engineer, doctorate in 2008, I've started my working activity both as a researcher and as a freelance in the industrial automation field.
From a user perspective there are tons of things which impact so yes I agree. But I'm still impressed (in the wrong way) how much RAM java requires even for silly things.
About EF Core.. I don't feel so bad if I compare it with JPA but I suppose it is a matter of taste.
Constant reinstatiation is a bad thing I agree. I also dislike controller based aproaches BTW. This is why I prefer a funtional approach to REST (like in Vert.x web: no objects at all), while a persistent CRUD layer is ok of course.
Do not stop at the pure benches: if you dig in the repos of the tests you will discover that the fastest solutions (regardless of the tech/lang) do not really use an ORM at all. I've found code in the past where the ORM logic was passed by native queries mapped on DTOs.
Well I didn't use JPA lately at all but I didn't compare it to EF because it's not the same thing. Maybe Spring Data or Hibernate itself but JPA no. I mainly hated tracking no tracking thing. The way it works with save and update and mainly things not related to modeling
Born in 1979, engineer, doctorate in 2008, I've started my working activity both as a researcher and as a freelance in the industrial automation field.
Why (JPA != EF) ? From my point of view JPA == EF == SQLAlchemy.
Btw I've recently apreciated micronaut-data-jdbc. Unfortunately I've not found a way to mix in with Vert.x Web :/
JPA is convention while EF is full framework implemented. I used Spring Data without using JPA myself in some cases. So I dissliked some calls via functions or LINQ which are part of EF
Born in 1979, engineer, doctorate in 2008, I've started my working activity both as a researcher and as a freelance in the industrial automation field.
"C# with net core is more efficient performance-wise" might be but not that much in case of standard REST/CRUD. Worked with both, not noticeable to the end user, never tested the actual milliseconds and once browsed pages like link I'm quite sure opposite is true. And I mainly focus on Cloud and multiple DB access as those are usually most use cases.
However it's awful in many ways with it's horrible EF Core and it's disgusting approach of instantiating services, controllers and so. Creating and using Singletons because of the way it's dependency injection works was so horrible for me that I just gave up. And reason I tried it is because - Why would I create new controller, services, whatever, each request? Does that sound efficient for you? To me no and sorry but I really don't buy Microsoft way of doing things. It's not PHP, it's not interpreted language and I don't need that "singletons are bad" excuse. So in the end as developer who did both I would never go back to C# even if it's more performant in these cases.
Your negative comments on EF Core have lead me to open a new spare time project to re-evaluate it! Shame on you :P
Ahahaha, good, if I'm wrong you'll reply to tell me I wasted your time, if not then nice proof of concept
From a user perspective there are tons of things which impact so yes I agree. But I'm still impressed (in the wrong way) how much RAM java requires even for silly things.
About EF Core.. I don't feel so bad if I compare it with JPA but I suppose it is a matter of taste.
Constant reinstatiation is a bad thing I agree. I also dislike controller based aproaches BTW. This is why I prefer a funtional approach to REST (like in Vert.x web: no objects at all), while a persistent CRUD layer is ok of course.
Do not stop at the pure benches: if you dig in the repos of the tests you will discover that the fastest solutions (regardless of the tech/lang) do not really use an ORM at all. I've found code in the past where the ORM logic was passed by native queries mapped on DTOs.
Well I didn't use JPA lately at all but I didn't compare it to EF because it's not the same thing. Maybe Spring Data or Hibernate itself but JPA no. I mainly hated tracking no tracking thing. The way it works with save and update and mainly things not related to modeling
Why (JPA != EF) ? From my point of view JPA == EF == SQLAlchemy.
Btw I've recently apreciated micronaut-data-jdbc. Unfortunately I've not found a way to mix in with Vert.x Web :/
JPA is convention while EF is full framework implemented. I used Spring Data without using JPA myself in some cases. So I dissliked some calls via functions or LINQ which are part of EF
I see. My mistake: with JPA I meant any of its implementations like Hibernate JPA or Eclipselink.