Using EF we can use LINQ to read data which is rather simple (especially using fluent calls), but we have less control unless we write eSQL on our own.
Is writing eSQL actually data store independent code?
So if we decide to change data store, can the same statements still be used?
Does writing eSQL strings in your code pose any serious security threats similar to writing TSQL statements as plain strings in C# code? That's why SPs are recommended. Could we still move eSQL scripts outside of code and use some other technique to make them a bit more secure?
ESQL is database independent in general, so it can be used like LINQ to Entities.
But please be aware that it has more serious limitations. It does not have DML, DDL, and DB-specific abilities.
The main ESQL disadvantage is that even simple query containing a couple of lines can be translated into monstrous SQL query for a particular DBMS, so one should check the generated SQL to be appropriate and analyze if it is optimal.
ESQL will not be executed directly on a database, it will be translated to SQL.
EF Security discussion is usually started from the connection string proptection, then model security is discussed, and only after that query protection is analyzed. It's up to the developer to decide if the peculiar query should be protected.
Related
I would like to ask the Entity Framework Core team what their ambition is for the scope/complexity of query translation compared to EF6.
I've used EF6 extensively and I know that if you can express it in LINQ and don't use any untranslatable functions, EF can probably translate the query correctly.
Will Entity Framework's translation be eventually as good as that, or is that something that is considered secondary, like the lazy loading feature.
If so, about what is the team eventually aiming at compare to EF6?
There's a ticket discussing GroupBy that appears to indicate they deem grouping an advanced type of query, but compared to what EF6 can translate, a normal group-by is pretty average.
(I'm asking here as the EF Core team says on it's site it is monitoring SO for questions.)
We took a very different approach in EF Core. Every LINQ query should work--even if you use untranslatable functions. We do this by translating the parts of the query we can into SQL and processing the rest on the client after the results are returned by the server. As EF Core evolves, we'll translate more and more of the query into SQL (e.g. GROUP BY) which can make it more efficient.
In theory, our goal is to translate everything that the store supports. In some cases however (especially on NoSQL stores) there simply is no translation for a LINQ operator, and we feel it's better to be functional and inefficient than to throw.
If you want to ensure your whole query is translated, you can disable client evaluation. This will cause it to throw like EF6.
I'm just starting to learn EF and now readind about Code First workflow. From what I gather, you would design your objects first and then the database would be created based on those objects. I can't seem to see the good in this. Why would you let your database schema be dictated by the hierarchy of your objects? Would you be able to optimize your database using Code First?
Also, as I have not read far enough yet, does Code First fully support DBMS features (indexes, triggers, sp, etc)? I ask as I've read in some articles that this is what most preferred (Code First). I have seen something about Code Second which is from what little I've read, I think is much better (existing database, but code centric development?), but maybe I'm missing something or haven't yet read enough and you guys can clear those things up. Thanks.
The capabilities of code first are the same since you have the same ability to express all the features of EF manually in your code. The main difference is that you don't use a designer to generate your EF code. This offers some benefits since you can decouple your entity classes from the EF context. The main benefit of this is that you can use plain old c# classes that aren't necessarily tied to EF if you decide to switch to another orm down the line.
The downside of course is that you have to hand code the entire model.
Keep in mind that you don't have to generate the database from your code. You can code against an existing database.
Could someone tell me if there are any times when it is more advantageous to use t-SQL over the Entity Framework? I'm aware of the N+1 issue, but is there any other gotchas I should be aware of? For instance, do Linq-to-EF queries cache as well as stored procedures? Are there instances where the SQL generated by EF is less than optimal?
Thanks!
Whenever you need to do the work "inside" the DB server and not go back and forth between your code and Server.
Also - when you use stored procedures, you can alter the code without recompiling/deploying, it might be easier on production environments.
IMHO it sometimes easier to code complex SQL statements in T-SQL rather than using LINQ....
I'm learning some ADO.NET. I noticed quite a few Database functionality can also be found in ADO.NET.
I'm kind of confused. Do I use ADO.NET to manage all the interactions or should I make call to the Database?
I don't know what should be done by ADO.NET and what should be done at the database level.
Thanks for helping.
If you mean what should be handled in SQL statements issued from ADO.NET, and what should be done in stored procedures stored at the database level, as much as possible in stored procedures, at least that's what I live by. In addition to eliminating the chance of SQL injection, stored procedures allow you to modify sql calls without having to recompile and deploy your code as well as they enable execution plan re-use by the query optimizer.
For example if I had this predicate format string, would that have the same security benefits like prepared statements in SQL offer?
#"name == $LAST_NAME"
I am not sure if this is a plain stupid substitution which still allows bad "SQL" injection to core data, or if this is just as good as prepared statements known from modern db technologies?
You are not running on a server and any user is going to get complete access to the sqlite file anyway so there is no security there to subvert.
In addition, this is a predicate and it is not a stored sql statement. When your application runs the predicate, Core Data will do the translation to sql, it does not store that translation.
In short, nothing to fear here.