3 ms·

We started a new project at work, and one of the decisions was "No EF", altho we've pulled in some not so nice looking queries (mixed casing / indentation), the

We started a new project at work, and one of the decisions was "No EF", altho we've pulled in some not so nice looking queries (mixed casing / indentation), the performance has been much better, and we can copy the query into management studio and check / optimize it. It's working out well. Part of the code reviews is asking how queries perform.

bob1029 6y ago
Being able to validate SQL at code review time is really nice. Seeing the diff in GitHub between old vs new SQL can very quickly tip you off to troubles. Having your DB logic locked up in EF makes this kind of thing a lot more opaque. You could hypothetically develop a code review policy where developers are required to attach a query plan for each modified SQL statement to the PR. If the biggest problem is whitespace/casing in your SQL, you are probably sitting in a really good position. This is something we do try to be strict about. All of our SQL lives as string constants in 1 file per database so it is really easy to keep track of what is being used throughout in a consistent way. We do not permit developers to write SQL strings outside of these files. It all has to be in 1 place. We have 1 file for all SQL commands that will ever be used against that database, and a 2nd file for its schema migration scripts.