Note: The feature tracked in this issue could help with using EF Core with database views. However, the feature is not limited to database views and its completion would not mean that every aspect of database view support has been implemented. See #827 for an overview of the areas where EF Core interacts with database views.

We want to enable modeling types that exist independently of entities but have no keys (and therefore are not updatable) as first class objects in EF Core models.

Relationship between query types and other features:

• We consider this a stepping stone to enable ad-hoc mapping for arbitrary types (Support for querying objects without keys #1862)
• The plan may involve enabling "defining queries", originally described in Support for defining query in query types #3932 for these types, because query types are not necessarily mapped directly to database tables or views.
• We could also have the ability to introduce a "null" defining query for query types that will only be used in ad-hoc queries. Note that defining queries (including null defining queries) could later be enabled for entity types, but we need a way to map CUD operations.
• One thing query types can help with is as the result type for Table-Valued Functions (covered by Query: Additional function mapping capabilities #4319). If we enable some kind of first class mapping of TVFs or even for TVFs using in FromSql() or defining query, having result types that don't need to have keys makes the feature much more useful.
• Query types are related to owned types conceptually. You could think about them as owned types that don't happen to have an owner 😄 (hence no identity, hence no ability to update)
• Query types are different but somewhat related to the idea of supporting database views. In the past when this has been brought up it was usually about mapping database views to entity types (e.g. Improved view support #827, RevEng: Support Views #1679) but if we have query types in the model then one could choose to map them to views in the database, and that would also be more flexible because database views don't necessary have keys and are not necessarily updatable.
• It could also be related to supporting the definition of views and the creation of views in migrations described at Create database views in Migrations using SQL generated from a LINQ projection #465.

Alternative names for the feature

We can consider renaming the feature to something else if we find a better name. So far the list is short:

• View types
• Structural types