views:

146

answers:

1

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.

  1. Is writing eSQL actually data store independent code?
    So if we decide to change data store, can the same statements still be used?
  2. 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?
+1  A: 
  1. 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.
  2. 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.
Devart
The main reason why I asked this in the first place was to use eSQL to better optimise actual DB queries.
Robert Koritnik
Let's have a case with a certain eSQL script that actually turns out to be *sour* (ie. monstrous). So if I optimize it on my particular DB, will it be optimized on other DBs as well? Or at least better as the original one? So it will gravitate toward optimised eSQL?
Robert Koritnik
Unfortunately, nothing is guaranteed. SQL optimal for one DBMS can be horrible for the other one.As you know, best performance in case of complex queries is usually gained only by using manually written native SQL queries (DefiningQuery for EntitySet or ObjectContext.ExecuteStoreQuery() in EFv4), or by materializing the entity collections returned from the stored procedures (using Function Import). But eager loading is impossible in these cases.
Devart