Hi,
I noticed in the latest version of aspnetzero that lazy loading is still not enabled. The proxy library is not yet implemented. I managed to implement lazy loading myself in my project but now i'm starting to doubt if that's a good idea.
Is there any reason why aspnetzero has not yet implemented lazy loading in the .netcore version? Missing key features or something? (For example any nav property now Must be virtual, otherwise it won't work at all)
Thx for the info.
11 Answer(s)
-
0
Hi,
Sorry for the late response. I was on vacation. Well yes. I meant lazy loading of Entity framework core.
As in the latest version of efcore lazy loading is supported (by using the dynamic proxy library of efcore) The only real question i have is do you guys plan to implement lazy loading in aspnetzero for this version of efcore or do you believe it's still lacking to much "basic" features.
Basicly i want advice on should i convert all my services to support/implement lazy loading or not. I just want to pick your brains because i'm sure one of your team has looked in to the progress and might have discoverd something i will learn the hard way. Wich might cause me to waste a lot of dev time or even worse make bad design choises.
Thanks for the information.
-
0
do you guys plan to implement lazy loading in aspnetzero
Actually there is no need to implement anything to support lazy loading. It is feature of EF Core. So you can use it without any implementations. Am I missing something?
do you believe it's still lacking to much "basic" features.
As I know there is any issue in ASP.NET Zero about this. You can also ask this question EF Core Team too.
-
0
hmm, i'm thinking you are not understanding me correctly
In .netcore lazy loading was not possible with Entity framework core 1.x. Since efcore v2.1 we have now the lazy loading support.
<a class="postlink" href="https://docs.microsoft.com/en-us/ef/core/querying/related-data">https://docs.microsoft.com/en-us/ef/cor ... lated-data</a> Because i do not want to inject ILazyLoader in all my classes( have a big class model) i can use the dynamic proxy library. But that's not an issue for me. It's my choice.
However, neither the dynamic proxy nor iLazyloader is implemented in aspnetboilerplate or aspnetzero. I've tested to confirm this and lazy loading for entity framework is not implemented in aspnetzero.
So my original question remains. Can someone clarify this for me? thx
-
0
According to the Asp.Net Core documentation you just need to add the following method call inside the AddDbContext setup in the PreInitialize() method of the framework core module?
options.UseLazyLoadingProxies();
-
0
I managed to implement lazy loading myself in my project in my original post... I know how to do it.
All i really want to know is
The only real question i have is do you guys plan to implement lazy loading in aspnetzero for this version of efcore or do you believe it's still lacking to much "basic" features.
Basicly i want advice on should i convert all my services to support/implement lazy loading or not. I just want to pick your brains because i'm sure one of your team has looked in to the progress and might have discoverd something i will learn the hard way. Wich might cause me to waste a lot of dev time or even worse make bad design choises.
-
0
It's a single line of code
options.UseLazyLoadingProxies();
What should AspNet Zero implement about lazy loading?
-
0
Hi Alper,
aspnetzero shouldn't do anything.
Let me explain.
When lazy loading is not activated, one must eager load. And thus write getallincluding and etc on their repositories where needed. So i have various protected methods in different appservices and managers that build my iquerable.
At current version of aspnetzero, lazy loading is not implemented. I am wondering will that change? This might not affect your code much, but will affect mine.
For example. At the current stable branch of my project, a dev in my team chose to reuse DTO's even though some navigation properties are not needed. those properties are at this point null. When activating lazy loading(because i like lazy loading) automapper will force ef to load those properties and changing the expected result. I figured out how to prevent this with an extra line of code where needed, but i don't really want to do that. I know this is not a good design choice, but due to some critical deadlines we won't update those dto's until we have more time on our hands.
But i still want to update our version of aspnetzero to the latest version before we modify those "badly designed" api calls in the near future.
So my real question is. Will in a future update of aspnetzero lazy loading be used and thus migrating to a new version be more time consuming(for us)? On that question i have ofcourse 2 follow up questions.
- if zero won't implement lazy loading, i'd like to know why. Not saying they should, just like to know what the motives are. Maybe i'll come to the same conclusion i also shouldn't implement lazy loading.
- if zero is planning to modify their appservice, so they use lazy loading, or just activate lazy loading by default. i'd like to know why they haven't already. Are some key features broken of EFCore lazyloading or the team just didn't get around to it or...
Just to be clear. I'm not saying anything is wrong with the current clean version of aspnetzero, or that anything should be modified.
I hope i made myself a bit more clear with this response.
-
0
<cite>TravelSoft: </cite> Hi Alper,
aspnetzero shouldn't do anything.
Let me explain.
When lazy loading is not activated, one must eager load. And thus write getallincluding and etc on their repositories where needed. So i have various protected methods in different appservices and managers that build my iquerable.
At current version of aspnetzero, lazy loading is not implemented. I am wondering will that change? This might not affect your code much, but will affect mine.
For example. At the current stable branch of my project, a dev in my team chose to reuse DTO's even though some navigation properties are not needed. those properties are at this point null. When activating lazy loading(because i like lazy loading) automapper will force ef to load those properties and changing the expected result. I figured out how to prevent this with an extra line of code where needed, but i don't really want to do that. I know this is not a good design choice, but due to some critical deadlines we won't update those dto's until we have more time on our hands.
But i still want to update our version of aspnetzero to the latest version before we modify those "badly designed" api calls in the near future.
So my real question is. Will in a future update of aspnetzero lazy loading be used and thus migrating to a new version be more time consuming(for us)? On that question i have ofcourse 2 follow up questions.
- if zero won't implement lazy loading, i'd like to know why. Not saying they should, just like to know what the motives are. Maybe i'll come to the same conclusion i also shouldn't implement lazy loading.
- if zero is planning to modify their appservice, so they use lazy loading, or just activate lazy loading by default. i'd like to know why they haven't already. Are some key features broken of EFCore lazyloading or the team just didn't get around to it or...
Just to be clear. I'm not saying anything is wrong with the current clean version of aspnetzero, or that anything should be modified.
I hope i made myself a bit more clear with this response.
As a customer, my opinion is that they absolutely should not use lazy-loading by default, and leave it up to the developer. Lazy-loading is the single worst aspect of entity framework, and it really upsets me that they caved and implemented it in EF core. It is singlehandedly responsible for nearly all EF performance issues in production websites.
-
0
my personal view is to disable lazy loading, why? here's the reason <a class="postlink" href="https://ardalis.com/avoid-lazy-loading-entities-in-asp-net-applications">https://ardalis.com/avoid-lazy-loading- ... plications</a> .
TL;DR:
Every database round trip eats up a lot of time and adds to the total time the user is waiting before their browser even gets back a response.
-
0
<cite>alper: </cite> my personal view is to disable lazy loading, why? here's the reason <a class="postlink" href="https://ardalis.com/avoid-lazy-loading-entities-in-asp-net-applications">https://ardalis.com/avoid-lazy-loading- ... plications</a> .
TL;DR:
Oh thanks for the link and response. Good to know that this is also the vision of Aspnetzero. This wil make me hold of on lazy loading. Thx!