Is there any setup for EF Core migrations to avoid chaining operations? I'm having stack overflow issues when there are too many chained operations.
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.
Does EF7 support EDMX approach?.How to use EF7 to execute stored procedure?.
Any suggestion is appreciable.
There is no EDMX support, but Database First Will Continue.Here you can find out more.
EF 7 will support multiple result sets in the future, but at this stage there is no support for them. You can track the Stored procedure support on this GIT issue.
Hope this helps to you.
EF Core, does not support EDMX, nor its preceding EF 6.x
In the other hand, it already supports stored procedures that returns result sets. The requirement is that the class this script will hydrate need to be declared as a DbSet in the DbContext.
Take a look at this thread for details.
Is Entity Framework faster than ado.net for Queries?
My test shows that ado.net is faster than Entity Framework in querying.Why?
ADO.Net is used by EF under the scenes. This means that overall EF is always going to be slower than ADO.Net (assuming they both are generating similar SQL statements)
However I have observed an interesting performance characteristic with EF5 vs ADO.Net and a low number of rows (either queried or inserted). EF5 appears to be consistently faster than ADO.net for under 10 items. I imagine this is due to an optimisation at connection setup time however I haven't yet tracked down what this is.
My results around this and a little more explanation is avaliable here
If anyone has any more information around why EF5 appears so fast on small datasets I would love to hear.
NOTE in this post I actually don't show the raw ADO.net results but they are very similar to the dapper results. I actually wanted to answer this specific question before posting the ADO.Net results :)
I found a very interesting in page: http://msdn.microsoft.com/en-us/library/cc853327.aspx
Here you can see during query stages, there is an stage named "Generating views" will cost a lot. Even though EF provides some method to pre-compile it, but if you have many query without pre-compile you still may get problems.
You can find How to: Pre-Generate Views to Improve Query Performance here: http://msdn.microsoft.com/en-us/library/bb896240.aspx
And here, you can see query without pre-generate will cost twice time. So that means it does cost a lot. http://blogs.msdn.com/b/appfabriccat/archive/2010/08/06/isolating-performance-with-precompiled-pre-generated-views-in-the-entity-framework-4.aspx
So I have a question, why EF design this stage? And does NHibernate also have this stage? If true, how about it performance in Nhibernate?
EF views have nothing to do with SQL views - EF views are mapping transformation compiled into executable code. EF use these transformation to convert its query representation into target SQL representation. The reason for this compilation is performance of the whole application - you need to invest time to initialization but all your subsequent queries and updates will use compiled code instead of some lookup in EDM. If you don't need to modify mapping at runtime you can even pre-compile those views during compilation of your application.
EF views are used for query preparation (transforming one representation into another) but the query preparation must be done for each unique query. In EF 4 this preparation is not cached unless you manually use Compiled query. In EF 4.5 and 5.0 (.NET 4.5) all queries are automatically "compiled" = there is the cache and each unique query is really prepared only once. Subsequent execution of the same query use compiled version from the cache.
You can read more about performance and EF 5.0 in this beginner guide.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I have an upcoming requirement, and I'm unsure if EF is the right approach.
Essentially I have a Web Service Contract to implement, that has a handful of methods that return specific classes (DataContract classes with DataMember'd properties so they serialize correctly). The data that makes up the classes will be the result of queries against a backend database.
At the lowest level, I know I can just write some stored procs in the database that will return data rows that I can manually wire up to the custom classes, and call the stored procs from within a Data Layer class (calls stored procs, returns custom classes).
I'm wondering if I can use ADO.NET Entity Framework for this, however my understanding that this creates Entity classes from the database tables. My custom classes don't resemble any of the database tables. The stored procs perform aggregations and table joins to produce the classes.
Am I missing something here from what's possible with the EF? Or would I be better just going with stored procs / manually wiring up the custom classes in a data layer?
The Web Service will be hosted in SharePoint 2010 therefore I'm limited to ASP.NET 3.5. I think I'd be using Patterns and Practices to access the data layer, unless there are better ideas out there.
Given that you have indicated that you can only use .NET 3.5, you would be using EF 1.x which wasn't widely accepted in the ORM community.
EF 4.x is much improved, but unfortunately requires .NET 4.
DAAB is certainly an alternative, but you will still need to map out your Service entities from the data (i.e. DAAB isn't an ORM)
IMO EF comes into its own when used with LINQ, especially when used with queries - if you find that you are writing many SPROCs of the form GetXXXByYYY (or using lots of ad hoc or dynamic sp_executesql) to populate your entities, then a LINQ enabled ORM makes a lot of sense. However, if you only have a few heavy hitting PROCs which have well defined interfaces, then an ORM may be overkill.
If the object model of your application remarkably differs from the data model in your database then I'd stick to the classic ADO.Net + stored procedures for aggregations and table joins. My opinion is that any ORM brings more trouble than benefit in such case.