In one of my projects, I am using an existing SQL Server database. All the database scripts are managed using DBUp and SQL script migrations.
In my application, I am using Entity Framework Core to communicate with this database. When I configure my entities in EF configurations, should I still define functions like IsRequired(), HasMaxLenth() etc.?
I am not using these EF configurations to generate migration scripts; all the migration is outside of EF. I am just using these configurations to communicate with the database.
When I configure my Entities in EF configurations, should I still define functions like IsRequired(), HasMaxLenth() etc.?
Other than table and column name mapping and data type mapping, it's not required, but additional model metadata might be used by front-end components for validation.
In general, yes, you should keep them. Many of these configurations are used throughout EF to make decisions at runtime. For example, some queries can be further optimized if EF knows that a column is never NULL, the max length is used to configure the SQL parameters it sends to the database, and unique constraints are used to sort SQL statements during SaveChanges.
While a few things like constraint names, non-unique indexes, index filters, and sequences aren't currently used at runtime, it's hard to know which ones EF will and won't use, so it's best just to keep them all.
And sometimes, database features like always encrypted on SQL Server, will fail entirely if the mappings aren't precise.
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 don't want to give my sql user the permissions to create databases.
Is there any way to create the database manually and then have entity framework create the tables inside it?
I'm certain EF Core is smart enough to handle this case. Just create the database, set your permissions and run the command dotnet ef update-database (assuming you have a valid migration).
Usually, an application (or multiple applications) use the same database from separate DbContext classes, which handle their own bounded context (a logical piece of the whole). That would require being able to recognize that Databases and Tables have already been created, and issue appropriate add and alter commands to the schema.
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.
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 am working on creating a service layer for a large sql server database (2008 R2) that is currently the backend for a winforms POS application with strongly typed datasets.
I think WCF is the way to go, and at first glance it seemed EF 4 was a good choice but now I'm having my doubts. Here is what I have found:
The stored procedure mapping isn't that great. I have hundreds of stored procs that I want to reuse. Most of them wouldn't return an 'entity' so the stored procs would have to be mapped to a complex type. Many of the procs use dynamic sql or temp tables so EF can't figure out what complex type to crete. Many of the procs return multiple result sets. I've read that EF extensions have a way to map stored procs with multiple result sets, but only for entities, so that doesn't help me.
Large models are a problem. There doesn't seem to be a good way to handle large entity models. The workaround of creating smaller models isn't that desirable and splitting the model loses design support, am I missing something?
EF mappings only go so far. The stored procs that I want to reuse return projections or information from many tables into a result set. There doesn't seem to be a way to map these results into entities, am I wrong? I've read about combining results from 2 table into 1 entity, but that only works if the tables have the same primary key.
Are people using EF in large scale existing databases? If not what would you recommend?
I've used EF on large scale databases, but as you say, the support for SPs as you have got is not great. That's not specifically a failing of EF per-se - ORMs in general work on the same principle and have the same "limitation".
If you have lots of SPs and are mapping them to datasets, you'll have to do lots of work even without SPs in terms of no longer referencing datasets and referencing your domain model types through your system, so you'd need to have some way to map your SPs to your domain model and back anyway.