✅ 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.

help

Root Question Message

BlueJayBird12/9/2022

✅ 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.

Cisien12/9/2022

If you dont make them virtual, you dont get lazy loading, which just means you need .include

Cisien12/9/2022

Its best practice to use separate models for your api anyway

BlueJayBird12/9/2022

So, you're saying that AutoMapper is the way to go, and getting rid of the virtual part is bad idea. Right?

Cisien12/9/2022

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

Cisien12/9/2022

Cleaner in that each query doesnt need a mess of includes

Cisien12/9/2022

For comparison, lazy loading is disabled by default in core

Angius12/9/2022

.Select()

Angius12/9/2022

And remove virtuals preferably

BlueJayBird12/9/2022

Ok, I've read your comments, guys. I'll try to fix this next week. See you then.

Cisien12/9/2022

if you remove virtuals, you may go a step further and disable lazy loading explictly

BlueJayBird12/13/2022

I solved this by changing the following configuration in the EF context:

BlueJayBird12/13/2022

_context.Configuration.ProxyCreationEnabled = proxyCreationEnabled;

BlueJayBird12/13/2022

This seems to have disabled the use of virtual fields in the entities I was retrieving from the DB using EF.

Contact Frequently Asked Questions Join The Discord Bugs & Feature Requests Terms & Privacy