I would like to recreate a 10 years old application with newer Technologies like ASP.NET WebAPI, AngularJS and the EF. Unfortunately, I have to stick to the existing database as the new webclient will run parallel with the existing one.
The difficulties:
- Some tables are cleared and refilled with data from other systems every week
- Many tables are referencing each other on non-primarykey fields.
- A lot of the Update/Write logic has been done with stored procedures so far.
Because of the first two things I am not able to use navigation properties when I just create an .edmx Diagramm from the existing db model. The only Workaround which came to my mind, is to use views (updatable views) for the tables without primary keys and just add the missing primary key field to the view.
Unfortunately, all changes made to the .edmx file have to redone whenever I update it from the model.
Is there any better solution? Does it even make sense to work with EF when using a database like that? I would probably still like to go this way because I could at least improve my EF knowhow.
Related
Our team is thinking of utilizing Entity Framework Core code-first to help model the database. We can have both DB projects and EF models, as per article here Database Projects vs. Entity Framework Database Migrations utilizing schema compares, just trying to figure out what will be the source of truth?
Does Entity Framework support all features in SQL Server SSDT Database Projects?
What features does EF Core 2 not support? (eg, does it not support any of following: triggers, views, functions, stored procedures, encryption keys, certificates, db properties (ansi null, quoted identifier), partitions)
I am trying to locate the Microsoft Resource.
tl;dr Database Projects are feature-rich, but database-first. Migrations is code-first, but has a very limited built-in set of database features.
For many people it won't be relevant to compare Database Projects and Migrations. They represent two different modes of working with Entity Framework. Migrations is code-first, DP is database-first. Sure, you can use migrations to control the database schema and besides that keep a DP in sync with the generated database to satisfy DBAs (as the link suggests). But both lead their own separate lives and there's no Single Source Of Truth.
So comparing them is useful if you're not sure yet wich working mode you're going to choose.
For me the most important difference is that DP will cover all database objects and detect all changes between them when comparing databases. Migrations only detect changes between a database and the mapped model. And the set of options for generating database objects is very limited. For everything you need additionally you have to inject SQL statements into the migration code. These statements are your own responsibility. You have to figure out yourself if a migration needs an ALTER PROCEDURE statement or not (for example). EF won't complain if the script and the database differ in this respect.
This is the main reason why I've never been a great fan of migrations. It's virtually impossible to maintain a mature database schema including storage, file groups, privileges, collations, and what have you.
Another advantage of DP is that they're great in combination with source control. Each database object has its own file and it's very easy to check the change history of each individual object. That's not possible with generated migrations. Indeed, many intermediate changes may never make it to a generated migration.
Of course the obvious advantage of migrations is the possibility to do a runtime check (albeit incomplete) whether the code and the database match. In database-first projects you need to create your own mechanism for that.
EF Core is only ORM.
1) You should be ready to create all DB objects except tables manually. What I create manually: constrates (defaults as well as conditions). Since this is code first - there is no need in SP, functions and so on. If you use ORM - DB is only storage. Of course practice is important. For me default constraints adds comfort on tables where I create test data manually. And conditions also are usefull in situations when you do not trust your (team) code.
2) you will do creation (and dropping) of views, triggers, sp and so on to the "migration" code (there is such concept in EF) in plain sql:
migrationBuilder.Sql("CREATE VIEW ...");
As a result you could have a separate "migration" program (e.g. command line tool) that install or remove both Ef Core tables and your manually created objects, do and revert the data migrations.
"EF Core migrations" is quite complex api (reserve a week for learning). Interesting topics: managing several dbcontexts in one db, createing db object during migration from model annotations, unistall. Or find a freelancer for it (this part of project is good for outsourcing).
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.
Our database has about 500 tables we'd like to use in our EF model. Of those I'd be happy to start with 50 or fewer just to get our feet wet after working in plain ADO.net for years.
The problem is, our SQL server contains many thousands of other tables that exist in our database that have been created through the years and many that are dynamically generated. Believe it or not:
select count(*) from INFORMATION_SCHEMA.TABLES
73261
So that's a lot of tables. I have found that pretty much every tool I've tried to design, build or template EF models or entities either hangs or does not return a list of tables. Even SQL Server Object Explorer in VS2012 won't list the tables and instead shows the Tables folder with a little "x" over the icon. So I can't even select a subset of tables.
What options do I have for using EF? Is there a template where I can explicitly define the tables that I want to use entities for? Even with 50 tables, I don't want to hand code each one in an empty EDMX.
Using a Database / Code First approach and avoiding connecting Visual Studio to the database at all (i.e. don't create an edmx, or connect with server explorer) would allow you to do this easily. It does not give you any of the Model First advantages, but I think it sounds like your project would be better served with a Database / Code First approach anyway as:
You have an existing Model, and are not looking to push changes from your EDMX to the DB
You are looking to implement this on a subset of your database
This link has a good summation ( Code-first vs Model/Database-first ) with the caveat that in you case a Database/Code First approach does not have you pushing changes from code to the Database, so the last two bullets under code first apply less, and yours is a Database/Code First hybrid.
With 70k tables I think that any GUI is going to be tricky. When I am saying Database / Code First, I am trying to convey that you are not using the code to create / define and update your Database. Someone may be able to answer this more succinctly / accurately?
I now this is an old question. But for those who land here on a google search. The only tool I have found that actually works with thousands of tables is The Sharp Factory.
It is an ORM. Pretty simple to use. So if you are looking for an ORM that can work with a large number of tables and does not require you to write "POCOS" or "Mappings" or SQL then this is the tool.
You can find it here: The Sharp Factory
Is it possible to use Entity Framework 4.3 without linking the model to an actual DB in the back-end?
I need to build a conceptual model of a database in the VS designer and then I'd like to manually handle fetches, inserts and updates to various back-end databases (horrible legacy systems). I need to be able to do this without EF moaning about not having tables mapped, etc. I realise that this is a very odd thing to want to do...
The reason for this is that we would like to move from these legacy systems into a well designed data model and .NET environment, but we need to still maintain functionality and backward compatibility with the old systems during development. We will then reach a stage where we can import the old data (coming from about 6 different databases) into a single DB that matches the EF model I'm building. In theory, we should then be able to switch over from the hacked up EF model to a proper EF model matching the new data structure.
Is this viable? Is it possible to use the EF interface, with LINQ without actually pointing it to a database?
I have managed to query the legacy systems by overriding the generated DbContext and exposing IQueryable properties which query the old systems. My big fight now is with actually updating the data.
If I am able to have EF track changes to entities, but not actually save those changes. I should be able to override the SaveChanges() method on the context to manually insert into various legacy tables.
I'm sort of at wits end with this issue at the moment.
UDPATE 4 Sept 2012: I've opted to use the EDMX file designer to build the data model and I generate the code by using T4. This enables me to then manually write mapping code to suit my needs. It also allows me to later perform a legacy data migration with relative ease.
If I were in your situation I'd setup the new DB server and link the legacy servers to it. Then create stored procedures to interface with EF for the INSERT/UPDATE/DELETE. This way your EF code remains separate from the legacy support messiness. As you decommission the legacy DB servers you can update your stored procedures accordingly. Once you have no more legacy DB servers you can either continue using your sprocs or do a refresh of your EF data connection to use the table schema directly.
Entity framework is to link entities to a data store without manual populates.
Otherwise you're just using classes with linq.
If you mean you don't want a seperate data store like sql server, mongo etc etc, then just let your application create the database as an mdb file that gets bundled in your app_data file. That means you don't need a databsae server so to speak and the database is part of your app.
If on the other hand you want a different way to save to the database, you can create your own data adapters to behave however you like. The mongo .net entity framework component is an example of this.
Alternatively, using code only you can just use stored procedures to persist to the database which can be a bit verbose and annoying with EF, but could bridge the gap for you you and allow you to build a good architecture with a model you want that gets translated into the crappy one in your repositories.
Then when the new database is ready, you can just rework your repo's to use savechanges and you're done.
This will of course only work with the code only approach.
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.