Modeling entities for specific applications - Entity Framework

Question

Hi, I have 2 applications:

1. Manager UI - Which should be able to create a user with all its fields (username, email, age etc.) and display them.
2. Core component - which only need the UserId and Username field, and need to be very performant. It also shouldn't be able to write to the database.

It seems I need 2 different models, one for the UI application and a second one for the core component. When I create the 1st model, life's good. But when I try to create the 2nd model, I get all the unneccessary fields. If I try to delete them - I manage to do that only for the nullable fields, but not for the required ones (which is only required for saving, actually). Here's what I get: "Column Users.email in table Users must be mapped: It has no default value and is not nullable."

Setting the "email" field as private getter & setter will not solve my issue, since I don't want to store the value at all on the entity (and fetch the field from the database) - as I said, this application needs to be as performant as possible.

I believe that if I could somehow set the model as read-only, it will solve this, but it's only a hunch (and I couldn't find a way to do that - is therer?)

Any help would be appreciated. Thanks, Nir.

Answer 1

There is no such thing as a "read-only" entity model. You can, however, do a read-only query by setting the MergeOption value so that changes to entities are not tracked. You can also select only the columns you need in your application by projecting into an anonymous type instead of returning an entity type in your queries. So you would use the same model in both applications, but in the "core component" you would use the model differently, in a way which delivers better performance for read-only use.

Answer 2

EF was really designed for you to gen the model for each specific use case. You are not supposed to need to gen a single large monolithic model because they are so easy to build and update (that was the theory anyway).

So I would say you should generate 2 models - one for each use case scenario. This means you only need to include what is absolutely necessary for each use case.