I enjoy using query types with views in order to perform advanced queries that I cannot do via EF transformations.

Right now, I am forced to use arbitrary SQL statements in migrations to build my views. This is very cumbersome. I wish to define my views as part of the query types in my model, in a similar way to how tables are built from the entity types.

I want migrations to pick up the view definition from my model and recreate the view as needed on any changes to it.

This would enable two things:

1. Have an authoritative definition of the view in one well known place.
2. Separate the delivery of query types and views from the delivery of migrations.

Perhaps the second deserves more explanation. I am making a library that supplies part of the entity/query model to the users of the library (e.g. imagine a "template" product from which customer-specific instances are created). The users of my library own the migrations. If I want to use views as the backing objects for my query types, my only choice right now seems to be to nicely ask my users to add some SQL statement into a migration to actually create this view. This does not seem like a path that makes for happy developers.

I am quite willing to define the view as just an opaque (to EF) string if it saves me from having to arbirarily paste SQL into migrations.

I am interested in this for SQL Server.

Related: #465