2 deleted 1 character in body
source | link

Your colleague is essentially correct. But perhaps set in their ways.

At the end of the day EF is a fancy way to generate SQL commands. You trust that its syntax and generation methods allow you to express complex queiriesqueries and generate effecientefficient SQL.

But if you can just write that effecientefficient SQL yourself. You can skip EF.

This is particularly true for spocs, as once you start using them you have to abandon the EF query syntax and just run the sproc. You might as well use SqlClient.

However!!

You can take it a step further and not use sprocs either. Just hard code your SQL. The arguement that sprocs run faster isnt really true for parameterised SQL as it will be compiled on the first run.

Use this is to test your colleague. Do they really want to streamline their code, or are they just used to making sprocs and sticking to what they know.

Personally I do not use EF or sprocs and find sticking to SqlClient repositories makes for highly streamlined, organised and effecientefficient code.

Your colleague is essentially correct. But perhaps set in their ways.

At the end of the day EF is a fancy way to generate SQL commands. You trust that its syntax and generation methods allow you to express complex queiries and generate effecient SQL.

But if you can just write that effecient SQL yourself. You can skip EF.

This is particularly true for spocs, as once you start using them you have to abandon the EF query syntax and just run the sproc. You might as well use SqlClient.

However!!

You can take it a step further and not use sprocs either. Just hard code your SQL. The arguement that sprocs run faster isnt really true for parameterised SQL as it will be compiled on the first run.

Use this is to test your colleague. Do they really want to streamline their code, or are they just used to making sprocs and sticking to what they know.

Personally I do not use EF or sprocs and find sticking to SqlClient repositories makes for highly streamlined, organised and effecient code.

Your colleague is essentially correct. But perhaps set in their ways.

At the end of the day EF is a fancy way to generate SQL commands. You trust that its syntax and generation methods allow you to express complex queries and generate efficient SQL.

But if you can just write that efficient SQL yourself. You can skip EF.

This is particularly true for spocs, as once you start using them you have to abandon the EF query syntax and just run the sproc. You might as well use SqlClient.

However!!

You can take it a step further and not use sprocs either. Just hard code your SQL. The arguement that sprocs run faster isnt really true for parameterised SQL as it will be compiled on the first run.

Use this is to test your colleague. Do they really want to streamline their code, or are they just used to making sprocs and sticking to what they know.

Personally I do not use EF or sprocs and find sticking to SqlClient repositories makes for highly streamlined, organised and efficient code.

1
source | link

Your colleague is essentially correct. But perhaps set in their ways.

At the end of the day EF is a fancy way to generate SQL commands. You trust that its syntax and generation methods allow you to express complex queiries and generate effecient SQL.

But if you can just write that effecient SQL yourself. You can skip EF.

This is particularly true for spocs, as once you start using them you have to abandon the EF query syntax and just run the sproc. You might as well use SqlClient.

However!!

You can take it a step further and not use sprocs either. Just hard code your SQL. The arguement that sprocs run faster isnt really true for parameterised SQL as it will be compiled on the first run.

Use this is to test your colleague. Do they really want to streamline their code, or are they just used to making sprocs and sticking to what they know.

Personally I do not use EF or sprocs and find sticking to SqlClient repositories makes for highly streamlined, organised and effecient code.