Totally disagree with statement "ORM is knowing what goes to the dababase" this is exactly the reason why many avoid using ORMs because you have zero visibility when you save objects in c# and ORM does its magic on how and when to save actual data.
maybe I didn't explain this well enough. I come from a background where no one knew what lived in a database. Things like functions, triggers, and other things had just been added over time. The way I see it, using an ORM is about defining your database in code and thereby you can have it under version control, at least the structure. I agree that ORMs are tricky. I have been struggling myself over the years with concepts such as tracking and having to write custom SQL cause what the ORM generated was just slow. I guess the alternative is stored procedures. The way I see it there are no silver bullets, just different types of problems. The speed you get initially becomes complexity later on.
The more I read, the more convinced I am, that a friend's joke about EF is totally true: People use EF, because they don't want to learn SQL and are afraid to use it.
As I wrote in my article. It's important to know what SQL EF generates and for reporting queries, for example, you need to write your own SQL. It's important to know when to use a tool and when to rely on SQL. An ORM is NOT a replacement for SQL, it just abstracts away basic SQL.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Totally disagree with statement "ORM is knowing what goes to the dababase" this is exactly the reason why many avoid using ORMs because you have zero visibility when you save objects in c# and ORM does its magic on how and when to save actual data.
maybe I didn't explain this well enough. I come from a background where no one knew what lived in a database. Things like functions, triggers, and other things had just been added over time. The way I see it, using an ORM is about defining your database in code and thereby you can have it under version control, at least the structure. I agree that ORMs are tricky. I have been struggling myself over the years with concepts such as tracking and having to write custom SQL cause what the ORM generated was just slow. I guess the alternative is stored procedures. The way I see it there are no silver bullets, just different types of problems. The speed you get initially becomes complexity later on.
The more I read, the more convinced I am, that a friend's joke about EF is totally true: People use EF, because they don't want to learn SQL and are afraid to use it.
As I wrote in my article. It's important to know what SQL EF generates and for reporting queries, for example, you need to write your own SQL. It's important to know when to use a tool and when to rely on SQL. An ORM is NOT a replacement for SQL, it just abstracts away basic SQL.