I have a 3 tables which need to be joined for doing some queries. The tables are relatively read-only for specific duration of time. Only if there is need, we need to write them.
I want to avoid join on demand for these tables. So I was planning to use Indexed views. However, I didn't find a way to define a view from entity framework (EF 6.1).
Can someone please guide on this?
Regards,
Amit Rangari
There is no direct method for creating views from EF 6.
You need to write raw SQL to create the view, then execute it from a dbMigration. For details see: https://msdn.microsoft.com/en-us/magazine/dn519921.aspx
You need to create the view via standard SQL statement (migration or the connection of the context). The view should have a key. After that you can map the view with EF like it was a table.
Related
Is there a way using Entity Framework Core to get nested data without having to iterate through it? like a simple SQL select with joins i would like to show all data on the same table
Sounds like you know the SQL you need to get the data you want. So I suggest you create a database view and then map your ef entity to that. As long as you are just reading ef will treat the view just like it would any other table.
I think youre looking for .Include() and .ThenInclude() methods that allow you to load related data in a eager way.
More on that topic on the official entity framework documentation at MSDN
I'm working with a legacy database that I can't easily create an entity model over because it uses extension tables with what is effectively composite keys and EF only supports single column keys for mapping one entity to multiple tables.
So, what I've decided to do is create updatable views (with INSTEAD OF triggers to handle CRUD operations) over the top of the legacy tables (which cannot be touched) and then have my entity model (either using EF or DevExpress XPO) built on top of the database views. This will also allow me to do stuff like easily add sub-queries in the select clause to retrieve child counts on parent records when retrieving a list of parent records in a single query.
However, I don't particularly want to manually write the SQL for all the views and triggers so I thought I'd use data model defined in the .EDMX file and t4 templates to help me generate the bulk of the T-SQL needed to create the views and the triggers. I thought there would be some template that I could use as the basis for doing this, but seems that's not so easy to find.
Can someone please suggest a t4 template that I could use as the basis where mappings are being retrieved from the .EDMX. Alternatively can anyone advise how to use the StorageMappingItemCollection to retrieve the mapping information from the EDMX file. I know a few people have said that apparently you can't use it or that they just use Linq to Xml, but I would have thought it should certainly be possible to use the StorageMappingItemCollection class as a strongly typed class to access this data.
Any examples of how I could use StorageMappingItemCollection to access mapping info would be very helpful. Thanks.
See http://brewdawg.github.io/Tiraggo.Edmx/ you can install it via NuGet within Visual Studio and it serves up all of the metadata from your EDMX files that Microsoft hides from you, very simple, works great.
I just started looking at Database Views with Code First... and try to decide if I should use them.
Here Ladislav recommends to use NotMapped inheritance parent for table and Db-View (my view only adds sums of child entities)... but how this work with CF Migrations? I really want to use them.
Also... navigation properties will work on Db-View Entity?
Is there any way to save data directly into Db-View entity (and it's table)?
If you want to use code first and migrations you should not use views. Views are database "logic" constructs and code first is not an approach for creating database logic. With code first you should use the projection which is also mentioned in the linked answer.
Migrations will not be able to detect changes related to your views. You will have to write all migration code for views manually.
If you want to use views you should do database first (= no migrations) and either map them with EDMX or code mapping.
Also... navigation properties will work on Db-View Entity?
This is the only scenario where code mapping provides better support than EDMX. You can define relation in your model even if it doesn't exist in the database (but your database must ensure data integrity). It is in theory possible with EDMX as well but it requires changing EDMX manually.
Is there any way to save data directly into Db-View entity (and it's table)?
Yes but your view must be updatable. I don't think that view with aggregation values is updatable.
I have a model in my project that maps to a LOT of views in my database, but I need to map to a view in another database.
How can I do this? Do I have to create another model? I don't want to, but I will if I have to.
The same model can't get data from the two different DBs. The easiest way would be to create a view in the same database that calls and returns data from the other database i.e. the abstraction view that internally calls external DB view.
If your database supports synonyms, you could setup a synonym to the other database, and merge the edmx definition in with your 1st database's definition. I wrote how to do it here
Basically you end up with two edmx files, and a script that merges the two into a working edmx file. Synonyms are used to reference one database from the other without needing the full database path.
If you use code first approach in Entity Framework, here is how to map EF entity to the table from other database:
SQL Script that needs to be run in your database to create synonym for the table from other database:
CREATE SYNONYM OtherDatabaseTableSynonym FOR otherdatabase.dbo.otherdatabasetable
Entity Framework Mapping in (Fluent API):
modelBuilder.Entity<OtherDatabaseTableEntity>().ToTable("OtherDatabaseTableSynonym").HasKey(x => x.id);
I've been scratching my head over this for over a week now and haven't gotten anywhere :( We have an existing legacy DB that I'm trying to model my entities against. The tables are extremely bloated and we do not have enough bandwidth to create new, optimized tables. So I'm having to work with what we already have. However, I do not want to use all the redundant columns that are exposed by the DB. My initial plan was to use Views in my Model but that is looking to be equally hairy with very little documentation around.
Now, what would be the best way to go about creating a Model with just a select few columns? All I need is a bunch of read-only entities; so if there is a way to ignore non-nullable columns from the schema, I'd be all set. I was planning on making use of POCOs else I'd have to create my own mappings I reckon.
UPDATE: By POCOs, I mean I'd like to use the ADO.NET POCO Entity Generator.
What about creating views in the DB, and only importing the views into the model?
Well, if you need only a bunch of entities and if they won't change a lot during time, than I would just pick the tables you need, generate the entities with the normal wizard and all collumns, and than delete all not needed collumns manually in the model designer.
add the table to your EF, and just delete the properties you don't want. it just won't map those DB fields.