✅ Is it possible to disable these properties on EF6? Web API 2 project, multi-layered, NF472
SCENARIO
- Solution type is NET Framework 4.7.2 (it is, what it is).
- I have this project, I'm consuming theses objects from the DB through EF (data layer), see image 5 . Information goes through to other layers before reaching out to the web API layer,
- Web API works (image 1), I can make a request and get data back as seen in Postman (image 2) and browser (image 3).
- I was getting this error https://stackoverflow.com/q/19467673/7389293 which I solved by just using a rough DTO to pass what I get from EF, I'm planning on using AutoMapper down the road.
QUESTION
- Is there a way to not generate those
public virtual fields on the EF classes? So I can throw the object from the EF right away into the API response.Stack Overflow
Entity framework self referencing loop detected
I have a strange error. I'm experimenting with a .NET 4.5 Web API, Entity Framework and MS SQL Server. I've already created the database and set up the correct primary and foreign keys and relation...
8 Replies
If you dont make them virtual, you dont get lazy loading, which just means you need .include
Its best practice to use separate models for your api anyway
So, you're saying that AutoMapper is the way to go, and getting rid of the virtual part is bad idea. Right?
Not automapper specifically, but split models from your db and your api. Disabling lazy loading is your choice. There are pitfalls to using lazy loading, such as slower queries because they pull back excessive data, but code is much cleaner
Cleaner in that each query doesnt need a mess of includes
For comparison, lazy loading is disabled by default in core
.Select()
And remove virtuals preferablyOk, I've read your comments, guys. I'll try to fix this next week. See you then.
if you remove virtuals, you may go a step further and disable lazy loading explictly
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.I solved this by changing the following configuration in the EF context:
_context.Configuration.ProxyCreationEnabled = proxyCreationEnabled;
This seems to have disabled the use of virtual fields in the entities I was retrieving from the DB using EF.