The easiest way I found to solve this problem was by creating a view and configuring via Fluent Api that my entity is based on this view and not on the table itself.

In the configuration in the table where instead of informing the table you should inform the view:

ToTable("VIEW_USUARIO", "Schema_Data_Base");

Using ORM, it is always tricky to define more than one entity for the same table.

But because of this limitation we find out that we do not have to do this; that doing so increases the complexity of the system unnecessarily.

Do you need some fields just for reading?

Make a select (LINQ) to a new object type (possibly even anonymous) by returning only these fields.

Do you need to read and also change these few fields?

Maybe there is a conceptual error.

Only the entity knows the complexity of its state changes. For example, can you even change two attributes of an entity without it being in possession of the value of other attributes in order to be validated?

On the other hand , you as a programmer are a great connoisseur of the domain and suddenly know that you can make this change without risk, and consider the performance gain of not having to rescue the entire entity important to make this small change.

In this case, you can make the changes through UPDATE commands, neglecting to use the entity definition. This ensures performance and makes explicit that the change is being made without knowledge of the entity's full state because it has not been redeemed from the bank.

Using this option, you may want to define a repository API for this entity instead of always manipulating it directly through LINQ or direct commands, in order to centralize an object's persistence and retrieval of this type of entity, which can improve code overall expressiveness and reuse of custom persistence and recovery methods.