I'm working on an application that interfaces with a slightly odd database. The design of this database is pretty bad; there are basically no foreign keys (although there are columns that reference other tables, they're not set as keys), columns are named very ambiguously, and the structure does not lend itself to the kind of logic I'm aiming to do (mostly, it forces joins for operations that should be simple, and leaves you trawling through needlessly massive tables for things that could have been split).
Unfortunately, I'm stuck with this database. It's being replicated off a third-party system, so I can't change the table structure or anything. I can add stored procedures and views, though.
In the application, I've come up with a set of classes that I can work with much more easily. I've got quite a bit of experience with Entity Framework, so I'm planning to use that. My initial hunch is that I can add views to the database that return things in the format of my classes, and then from there on out just pretend that they're tables. I've never tried anything like this before, though, and I'm not entirely sure how to proceed.
How can I use Entity Framework to map my classes to these views? Note that it kinda needs to be my POCO classes, rather than anything EF auto-generates - is there a way to tell EF to map existing classes?
If you use code first then Entity Framework will generate CreateTable instructions in the migrations. To use a view instead, replace this code with your own Sql to generate the View. See the answer to this question: Mapping Database Views to EF 5.0 Code First w/Migrations
I would also configure Entity Framework to use stored procedures. Then you can tailor the insert/update/delete sql to match the underlying tables. Again, you can do this by altering the sql that is generated for you in the migrations.
Related
I wonder if it is possible to do postgres table inheritance in entity framework 7 - instead of the addition of columns do a "real" postgres with base table and table that inherit base table?
If so, how do I configure that?
Cheers,
Mario
This is definitely not supported. In theory you could create your database schema yourself with inheritance (so outside EFCore) and then mapping CLR entities to that, without EFCore knowing anything about the table inheritance. However, if the CLR classes themselves inherit from one another (as they should in general), that would likely trigger EFCore's own inheritance feature, which will mess everything up. If there's some way to tell EFCore to disregard the CLR inheritance you might be able to get away with it.
As for a more complete solution where EFCore is actually aware of PostgreSQL inheritance, that would probably be a pretty big task, which would probably involve changes in EFCore itself (and not just the Npgsql provider).
Can you please open an issue? I definitely won't have any time to work on this anytime soon but it's good to have it in the list.
I'm just starting to learn EF and now readind about Code First workflow. From what I gather, you would design your objects first and then the database would be created based on those objects. I can't seem to see the good in this. Why would you let your database schema be dictated by the hierarchy of your objects? Would you be able to optimize your database using Code First?
Also, as I have not read far enough yet, does Code First fully support DBMS features (indexes, triggers, sp, etc)? I ask as I've read in some articles that this is what most preferred (Code First). I have seen something about Code Second which is from what little I've read, I think is much better (existing database, but code centric development?), but maybe I'm missing something or haven't yet read enough and you guys can clear those things up. Thanks.
The capabilities of code first are the same since you have the same ability to express all the features of EF manually in your code. The main difference is that you don't use a designer to generate your EF code. This offers some benefits since you can decouple your entity classes from the EF context. The main benefit of this is that you can use plain old c# classes that aren't necessarily tied to EF if you decide to switch to another orm down the line.
The downside of course is that you have to hand code the entire model.
Keep in mind that you don't have to generate the database from your code. You can code against an existing database.
I have successfully run some tests with PostgreSQL and EF Code First and I know it works. I have an existing database that is quite large and it would be helpful if the EF Power Tools Reverse Engineer Code First method worked on my PostgreSQL database, but I can't seem to do that. I'm assuming its just not supported, but I'm wondering if anyone else has had success with that or perhaps with some other tool/technique for generating EF Code First types and datacontext for PostgreSQL. Any suggestions?
By the way - I can generate the basic types easily enough off off some information_schema queries against the DB, but I'm shying away from going beyond simple types without navigation properties. To generate the navigation properties and datacontext and mappings would be more of a pain in the arse and I have a feeling that would just get too hairy.
I'm bit confused: with all the evolutions of EF i'm not sure where i'm now.
*Is EDMX a choice of the past and should be used any more ?
*If so what is the best choice ?
*I hate edmx, can i upgrade to code first ?
It is not clear what all this EF versions are to me
Thanks
Jonathan
For a lot of apps you can start using Code First if you want to. The one big thing Code First doesn't support yet is mapping to stored procedures. (You can still call stored procedures, but you can't map entity CRUD operations to them.)
That being said, doing Database First with an EDMX is still absolutely supported and a fine choice, especially you like using the EF designer.
EF 4.1 and above fully support both Code First and Database First.
Personally, I would almost always choose Code First, even with an existing database, because I'm a code-centric person and would rather keep all my mappings in code where I can easily refactor, manage in source control, split into multiple files, etc. For me, it's much easier and nicer to deal with code artifacts than monolithic XML documents.
This is how you should evaluate your Entity Framework usage:
1) EDMX is a totally valid option specifically if you have an existing Database and want to generate your entities based on your database schema. One of my favorite benefits to this can be rapid data layer development with low risk. Also mapping stored procedure results to classes is always nice when you have complex existing stored procedures to work with.
OR
2) Code First is a totally valid option specifically if you want to create you database based an object oriented data model. With code first its easy to make big refactors that you don't always think of till implementation time. Source control is more common with code and shelving/rolling back are beautiful features.
TL;DR version :
They are both totally viable options. Neither are outdated ;nor shall they be any time soon.
We had performance consideration in warm up EF Code First. EF Code First take some minutes to start, because we have thousand Entity. so this bottleneck enforced us to Use EDMX, and used Interactive Pregenerated to Create EDMX from Code First in First Run after entity Model changed, and at Other First Run warm up time considerably lowered.
but story not end at that. after doing that we saw in Development area we have many change in Entity Model, so after each change EDMX File should be recreated(update) very often. so we decide to Create EDMX Programatically and Optimize that creation for our Entity Models.
I'm trying to display the results of a sproc in my MVC 3 web app.
However, the sproc calls into 4 tables on one database and joins them with 5 views (single table views only, thank goodness) on another database. Each (SQL Server) db is on a separate server but that shouldn't matter.
I've read this: http://blogs.msdn.com/b/swiss_dpe_team/archive/2008/02/04/linq-to-sql-returning-multiple-result-sets.aspx
and this:
http://www.codeproject.com/KB/dotnet/linqToSql5.aspx
and still cannot determine whether I should use the dataContext classes or just embed the straight SQL.
Perhaps there is a better way to return my results than LINQ to SQL (15 columns, 3 different data types)? I need to update the tables as well. The user will have the ability to update each value if they choose. Is this a task best suited for the entity framework classes?
I plan on using the repository pattern so I can change data access technology if I must but would rather make the correct decision the 1st go 'round.
I was hoping for a resource that was more up-to-date than say, NerdDinner and more robust than the movie apps for MVC3 that abound, particularly implementing the sproc results inside a view. Any suggestions would surely be appreciated. Thanks.
Once you plan to "update" data then you are going to handle it all through stored procedures. Both Linq-to-sql or Entity framework will not help you with this because they are not able to persist changes to something created from arbitrary query. You should very carefully check if you are even able to track the data back to the correct record in the correct table. Generally result of a stored procedure is mostly for viewing the data but once you want to modify the data you must work with each table directly or again use some stored procedure which will do the task. Working with tables from multiple databases can be pretty complex in entity framework (EF doesn't support objects from multiple databases in one entity model).
Also what you mean by 15 columns, 3 different data types? Stored procedures support in both Linq-to-sql and Entity framework will return enumeration of one flattened data type containing 15 properties.
I'm not aware of anything that linq-to-sql can do that Entity Framework can't really, so EF seems to be a better solution in this case. You can add a stored procedure to your Entity Framework model as well, so you can just have it call the procedure and deal with whatever comes back.
Since the end goal will involve accessing the same Databases with either technology and they will be using sql to retrive the data either way its really a subjective anwser.
I would use whatever technology you are most comfortable and focus more on the implementation. Both data access platforms are based off of ado.net technologies and are for the most part equally powerful.
Regardless of the technology I would evaluate how the data is accessed and make implementation decisions based on that.