How can I use MVC4 Migrations without using Entity Frameworks? I would really like to use data migrations but I am not using Entity Frameworks. I am using dapper-dot-net.
Yes, you can use Migrations without using Entity Framework. All Migrations cares about is the metadata it uses to manage the database and you need to use some EF stuff to handle that, but you then don't ever need to use EF to actually access the database. This blog post describes the process in detail: http://weblogs.asp.net/fredriknormen/archive/2012/02/15/using-entity-framework-4-3-database-migration-for-any-project.aspx
Check out Insight.Database.Schema on NuGet. It gives you a lot of the magic of migrations without the hassle of EF. I'll be updating the docs on github over the next few days.
Related
I am wondering about designing a EF core model of the SAP B1 database. I realize that this is a major undertaking, but I aim to start small.
This is mainly as an exercise, which may lead to something in the future.
My main issue right now, is to ensure that the DbContext is read-only.
I have found several suggestions, like this one:
How to make Entity Framework Data Context Readonly
However, that is for the Entity Framework "standard" not core, and the accepted solution does not seem to be possible with EF Core.
So, aside from using a login without write permissions, how would I go about making a read-only DbContext?
I am using EF Core 5.0.
I faced a situation where I need to maintain some database tables in sync with a Rest API. There is a daemon that keeps hitting this endpoint and has to sync the related tables.
I'm using ef core and I found only the standard Add and AddRange methods but nothing like Upsert or Synchronize. I searched a little bit and found that some proprietary nugget packages provide this but I need something open-source.
Is there a reason why this is not supported directly in EF Core ?
The project currently I'm working on, it has been changed to fluent migrator from EF migrations. What are the benefits of fluent migrator over ef migrations? Is it really worth using over EF migrations?
EF migrations are inherently code-first - you write model first, run ef commands to generate automatic migration and then update the database. No matter how sophisticated, automatic migrations are always problematic. First, things like column renames, dropping unused columns are always problematic. Additionally, if you are using F# record types or C# POCO objects, then to facilitate migrations, you often have to decorate your plain DB entities with migration specific attributes which are not desirable.
Second, EF migrations are not easily package-able as a standalone console app. Packaging migrations into a separate executable app are always a better idea as the consumer of your application would not have worry about knowing the specific commands like entity framework migration commands. Packages like FluentMigrator and DbUp makes it very easy to package into executable. However, it depends on the application needs. For example, if you are building off-the-shelf application like open source Wordpress style blogging engine and if your audience is not well versed with .net core, then migration as a dedicated utility is helpful.
You might want to choose to run ef migrations programmatically but that again is an anti-pattern as in container world, multiple container might yield race condition and needs special care, thus always better to have separate console project for this.
Is it possible to deploy / install Entity Framework Core 2.0 alongside traditional Entity Framework 6? Is it fully possible, or possible but with some hang-ups, or not possible? Is this documented somewhere? I think I've seen they said they designed it to be side-by-side, but I'm having a hard time fully confirming this. Thanks.
The official documentation says the following:
It is possible to use EF Core and EF6 in the same application. EF
Core and EF6 have the same type names that differ only by namespace,
so this may complicate code that attempts to use both EF Core and EF6
in the same code file.
If you are porting an existing application that has multiple EF
models, then you can selectively port some of them to EF Core, and
continue using EF6 for the others.
This means of course that you can install both EF6 and EF Core in the same project. I have done this in a few simple cases myself and it was working ok.
I currently generate XML from my single source of truth and save it as an Entity Framework EDMX file and then use the EntityClassGenerator object to create the classes from the diagram. Is there a way to generate the classes without having to create the XML file first?
I haven't heard back from Ladislav Mrnka, so I'll put his comment here as an answer. Using the Entity Framework's new Code-First, I can have a code-centric development workflow where my generator will create POCOs and a custom DbContext, then my database will be generated from the POCOs using convention instead of configuration. No need for an EDMX at all!
Here's a good explanation of it: http://weblogs.asp.net/scottgu/archive/2010/12/08/announcing-entity-framework-code-first-ctp5-release.aspx
EF needs the metadata from the EDMX at runtime. Even if you could use CodeModel or something to generate the entity classes, they would be useless to the EF runtime without the metadata describing the storage model, mapping etc.
Fabio Scopel has a webcast on youTube where he shows this Beta Tool (back then) called Entity Framework Reverse Engineer.
Check the link Entity Framework 5.0 - Code First Reverse Engineering existing DataBase