A colleague and I have been trying to augment an existing database with entity framework code first and we are having no luck achieving what we need to do.
In a nutshell, we have an existing database which has a user type InternetUser. We are upgrading the project and trying to integrate the MembershipReboot code. That code has a concept (and entity) of a UserAccount. So, we decided that we would connect these two types with a foreign key in the InternetUser object that references the primary key (a GUID) of the relevant UserAccount object.
We created our entities by using the entity framework Power Tools and reverse engineering. We then manually connected the InternetUser type with the UserAccount in MembershipReboot by including a UserAccountId property.
The complexity in this migration comes from the fact that some hashing (cryptography) code in the MembershipReboot library needs to run whenever a UserAccount is created. I am not quite sure how to do that in the seed method using EF code first. So, it is not just a case of running a SQL script when seeding. Some C# needs to run to create the user using MembershipReboot.
If anyone has tried to accomplish something similar, I would love to hear from them and how they solved the problem.
Related
How to create View (SQL) from Entity Framework in ABP Framework
Not allowed to post comments because of reputation. Just trying to get more information on connecting a database to an Entity Framework, without having to switch to a code-first development style. View selected answer's response (he told the OP to basically do the same thing he was going to do in the DB but with EF, and then added an extra step where EF "...ignores..." the previous instructions...
I want to create tables and design database directly in SQL, and have the csharp library just read/write the table values (kind of like how dapper function where it isnt replacing your database, just working along side of it).
The tutorials don't talk about how to integrate your databases with your project. It either brushes over the subject, ignores it completely, or discusses how to replace it.
I don't want to do any EF migrations (i dont want/need to destroy/create database everytime i decide to run, duplicate, or transfer project). Any and all database back-track (back-up/restore) should be done with and thru SQL (within my work environment).
Just to be clear on exactly what i'm trying to learn:
How does somebody who specializes in database administration (building database schema, managing and monitoring data, and has existing database with data established) connect to project to fetch data (again, specifically referencing Dapper's Query functionality).
I want to integrate and design micro-services, some may share the same database connection or rely on another. But i just simply want to read data in a clean strongly-typed class entity, and maybe deal with insert/update somewhere else if i have to.
I would prefer to use Dapper instead of EF, but ABP is so heavily integrated with EF's design, it's more of a headache to avoid it, than it is to just go along with.
You should be able to map EF under ABP the same way as any other project using DB-first configuration.
The consistent approach I use for EF: (DB-First)
Define entities to match the table/view structure.
Define configuration classes extending EntityTypeConfiguration<TEntity> with the associated ToTable(), HasKey(), and any HasMany/HasRequired/HasOptional for relationships as needed.
In DbContext.OnModelCreating: modelBuilder.Configurations.AddFromAssembly(GetType().Assembly); to load all entity configurations. (assuming DbContext is in the same assembly as the models/configurations Substitute GetType().Assembly to point at the entity assembly.
Turn off Migrations. In DbContext constructor: Database.SetInitializer<MyDbContext>(null);
EF offers a lot more than simply mapping tables to classes. By mapping relationships between entities, EF can help generate optimized queries for retrieving data across those related entities. This can allow you to flatten data structures without returning unnecessary data, replace the need for views, and generally reduce the amount of data coming across the wire from the database to the application server.
In my spare time, I'm trying restart my effort to learn F#. I'm doing so by trying to create a simple application that will allow me to analyze my financial transactions.
My first attempt at creating this application failed due to the persistence step. I used SQL and the EntityFramework package, but the latter generated database entities, which I did not want to use throughout my application since they're all mutable (I think..). Instead I had to map these database entities to domain entities. Much manual glue code later it worked....until I found a bug and was forced to replace much of that glue code. That was the tipping point that made me quit.
On SO I found a question describing my situation, e.g. Saving F# types to a database. Mark Seeman suggested that the pain of mapping can be overcome if I'd not use objects for persistence. At work I have recently been introduced to MongoDb, which at least saves me the pain of mapping from database entities to domain entities. These entities all need some ID, and I chose to use an ObjectId from Mongo. Ooops, there comes the deja vu, in order not to have my domain entities being dependent on Mongo, I will once more have to create database and domain entities....as well as the mapping. Bah & Ugh.
In C# I'm used to do such mapping with tools like Automapper, but they don't really work for special F# types. So now I'm wondering what Mark Seeman ment by "using objects for persistance". How is this solved in F#? So far I haven't been able to fine more info on this topic besides the aforementioned question on SO.
I am using an existing database and my normal method is to add a new Entity Data Model and point it to the existing database. If I was to use the EF power tools and reverse engineer to make it 'code first' style what is the advantage of this ?
Both are classes that inherit from DbContext right ? So can someone explain to me what an advantage might be working with the code base over time if I was to use the EF power tools reverse engineer tool instead ?
Code First to an existing database generates your model (at runtime) from your C# classes. Database First stores the model inside of an .edmx file and generates your classes (at design time).
The video Entity Framework Development Workflows gives a good overview. Ultimately, it comes down to whether you want to maintain your model using a designer surface or using C# classes.
It is also worth mentioning that, if you want to use Code First Migrations, you have to use Code First since it currently doesn't work with Database First.
I can't seem to get my head around a comfortable solution for the following scenario:
Client / server application where server prepares an examination package file.
A package file is like a license for one examination session (one-to-one).
Package file is downloaded by admin, fed into a desktop client where student will be going through his exam session.
Client app records exam session, repackages the results for the admin to collect.
I am currently using TPT. The problem is I use an EDMX file to create the model, ignore the DB mapping, generate DbContext and POCO classes from customized templates and resume in a CF-friendly way from there as if the EDMX did not exist.
I cannot visualize how to structure these classes. Both the server and client package have a common Compile() method among others so it is natural to think about inheritance here. The package base class cannot be mapped since we want instances of both derived classes to exist in the DB.
But my grasp on EF breaks down when trying to consolidate inheritance with the TPT approach. I do not have control over changing from TPT to another approach. I wonder if EF can be instructed to treat specific scenarios differently. Can an entity class be derived from a non-entity class and how?
The method - Entity Framework Code-First - looks good. But its very difficult to create all the classes for a large database.
Is there any easy way to generate the Entity Framework Code-First classes?
You can use the recently released Entity Framework Power Tools CTP1. The tool gives you the ability to reverse engineer code first, meaning the Database will be mapped to Code.
Note that all tables in your large database will be mapped. There currently is no way to choose which tables will be mapped to code. Reading through the comments, this feature will most likely be implemented in a future release.
The point of EF Code-First is that you define your domain model in code, then your user-interface and database can be easily generated from that domain model. This has a number of advantages including reducing the amount of tedious code which needs to be written, and helping to ensure your database, your domain model, and your UI match each other.
However, at some point you are going to have to write your domain model - there's no way that can be "generated" (by which I assume you mean computer-generated) as it is personal to your application.
If I've misunderstood your question, please leave a comment and I'll update my answer.
If you want to use the code-first model, but already have an existing database, you can use the Entity Framework Power Tools to generate classes.
If you're reading this after May/2012, the above tool may be out of beta!
No there is no way to generate classes for you if you are using code-first. Code first means that there is no model and no database so you can't generate classes unless you have some upfront design in any case system (UML) which will autogenerate code for you. Simply generating classes without any input about how they should look like sounds like AI from Sci-fi, doesn't it?
If you already have databse you are not using code first but database first. In such case you can have your classes generated.
Check out the link below. It's a program that will generate POCO classes from your databases. I think that's what you're looking for.
http://msormcodegen.codeplex.com/
Generate the code from the database first using database first generation and then modify the resulting code to start your code first version