That totally makes sense! Thank you for your help. We will apply your solution.
Hi,
Consider the following code.
var proposal = await _travelOfferPriceProposalRepository.GetAll()
.Include(b => b.TravelOfferPriceProposalElements).ThenInclude(b => b.TravelElement)
.Include(b => b.TravelOfferPriceProposalGroups).ThenInclude(b => b.TravelOfferPriceProposalElements).ThenInclude(b => b.TravelElement)
.FirstOrDefaultAsync(b => b.Id == id);
///
// This code will automatically do hard delete the data we have. Without any notification.
// Due to UnitOfWork.
///
proposal.TravelOfferPriceProposalElements = proposal.TravelOfferPriceProposalElements
.Where(b => b.TravelOfferPriceProposalGroupId == null && b.TravelOfferPriceProposalId == id).ToList();
///
///
// Need to use this instead
var test = ObjectMapper.Map<TravelOfferPriceProposalDto>(proposal);
test.TravelOfferPriceProposalElements = test.TravelOfferPriceProposalElements
.Where(b => b.TravelOfferPriceProposalGroupId == null && b.TravelOfferPriceProposalId == id).ToList();
return test;
As you can see our software team has made the logical error of filter out data and storing it on the same entity, causing it to delete the actual data from our database instead of just doing a filterd get.
We understand the issue, however the above code causes a hard delete on our records. Despite the fact that TravelOfferPriceProposalElement is a full audited entity. Should that not be a soft delete?
Is this a issue/shortcomming of the ISoftDelete interface combined with EFCore or is this normal behaviour? If this is normal how can we log hard deletes for fullauditedentities on a application level?
We believe our team has made this mistake on multiple appservices.
Thanks in advance for any advice given.
Okay, would really like to know in to why you guys decided to start building from scratch again.(big fan of abp) Also, for the new Abp, wil an angular template be provided/supported?
Looking forward to the news letter.
Hi all,
This application is developed based on ABP vNext (https://abp.io/). So, not related to AspNet Zero product.
We developed this as a standalone module. We will have more modules like that and we planned to sell these modules in a module market (with "source code included" option). But it is very early days for the vNext.
We will make an announcement about the ABP vNext and reply all potantial questions in a very short time :)
Have a nice day.
<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!
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.
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.
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.
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
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.
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.
If your custom object has a pk that is a identity column in your sql server then you first must turn of identity before inserting.
Do note my advice is more regarding importing data in to your database one time only. If you want to do this on a live database or in production mode it's not really a good idea