I am just starting out with EF Code-first:
If I create a read-only EDMX file from my code first can I save this readonly file as a stand-alone file and then include the resultant file in my project without affecting code first implementation.
Even though I am doing code first, I like a picture as it helps when I am explaining the db model to others. But I do not want to included this if it effects the code-first approach
will adding the EDMX file to the code-first project cause problems with the code-first approach?
No it doesn't have any effect on your code First approach. You can add the .edmx file directly to your project from Add-> New Item and generate the model from database without affecting your code-first approach. Just remember to use different namespaces so you don't get namespace conflict between your code-first and model classes.
To remove the Model, just remember to delete the related connection string in app.config/web.config to prevent your config files from becoming messy.
Related
I've been using EF for a while (4 with model first) and so far I've not created any mapping manually. Whenever I need more entities/tables, I add an entity and the associations (all foreign key) and click "update database from model", which, as is well known, doesn't update any database from the model (although it does need a database connection for reasons I don't know). What it does is generating a storage model and the appropriate mappings to it, which are all stored back to the same edmx xml file.
So far, that has always been enough for me but I'm wondering what the workflow would be if one is to tweak the mappings and storage model manually. "Update database from model" overwrites all manual customization - so how is one to fix most of the mappings and storage model? Because I clearly don't want to do it all by hand - in fact I couldn't even figure out how to actually create a table in the storage model other than by editing the edmx in the xml.
I have the same problem. I just use a mixture of methods. If I add a field to the database, I just add the field to the model file. If I do a major restructure, I delete the table and recreate it by generating it from the database. Sometimes, I actually edit the edmx as XML to change or add things. You just kinda gotta figure out what process works best for you. I have managed to avoid heavy customization in the edmx by using the T4 template or changing the database and regenerating.
What are the benefits of using ADO.Net Entity Model and EF?
Can we use both of them together in a project. I came across an example where, the user had used both edmx and ef for his application. I am not sure what is the purpose of that.
Thanks
Edmx artifact (either in the form of a file on the disk for Model First and Database First approaches or being generated by the EF runtime - Code First approach) describes your model, your database and the mapping between these. At the moment EF always needs it to work. The only nuance is that for CodeFirst applications (or, in general, applications using DbContext) this file is generated on the fly from your classes and you don't deal with it directly while in case of Model First/Database First where you use the ObjectContext the file is on your disk and (usually) is split and embedded in your assembly.
EDIT
EF6 no longer creates and uses artifacts internally (at least for CSDL and SSDL parts). However you can still dump the model in form of EDMX using EdmxWriter.WriteEdmx
I want to get rid of the big messy edmx file which has caused me nothing but pain when merging in svn.
I would like to move towards code first. For this, ideally I would generate the classes automatically based on the current edmx, then remove the edmx file completely.
I won't need a designer after that, I'll add columns and relations by hand.
How would you go about obtaining this? Would the new ef 4.2(?) be a better fit ?
Thanks
I would use the Entity Framework Power Tools CTP1
to generate the POCOs from your existing Database.
Entity Framework Power Tools CTP1
Reverse Engineer Code First - Generates POCO classes, derived DbContext and Code First mapping for an existing database.
After you have your POCOs and you Context generated, you dont need the
edmx file anymore.
I eventually generated the .cs files from the edmx changing the generator to "ADO.NET DbContext Generator" from http://visualstudiogallery.msdn.microsoft.com/7812b04c-db36-4817-8a84-e73c452410a2 .
Then added primary and foreign keys as they weren't generated (I am using a mysql db if it makes any differences).
Then I had to change a ton of queries because if before you could do :
from x in context.Table1
from y in context.Table2
where x.id = y.xid
and would translate to a join, this no longer works !
Quite a bit to change but eventually it seems to be working.
I created Model1.edmx file and accordingly Model1.Designer.cs was also created.
I decided to copy all code from Model1.Designer.cs to dal.cs file and deleted Model1.edmx + Model1.Designer.cs files.
When I try to connect I get error that mapping is failed and no SSDL,CSDL are found.
Is there any way to use Linq To Entites without .edmx file, but just using the code in Model1.Designer.cs?
If you define your mapping in EDMX there is no way to use it without EDMX. EDMX is necessary because the build process will decompose the EDMX files into multiple resources specifying mapping between classes and database. These resources are used at runtime.
If you don't want to have EDMX file you can't use it at all and instead you can try code first approach (more tutorials are available on that page) in Entity Framework 4.1. You can also use helper EF Power Tools to generate code mapping from existing database for you (it can be good to start learning how to map tables from code).
In Entity Framework, is there any way to make edmx file to automatically create entity when a table is added to the schema in the database and delete entity when a table is removed from the schema at run-time?
There is no EDMX file at runtime - there are only mapping files which are static XMLs. There is no mechanism controlling your database and modify these files if database changes (moreover as #marc pointed which files should be modified if you have more then one model?).
This is even doesn't make too much sense if you try to do it manually. Adding table to mapping is not enough - you also need a class and code which will use that class - both added at runtime.
There are more problems related to this. EF is tool configured at design time. The only exception is loading configuration classes for EF code first but again configuration classes are created at design time (I intentionally skip any ridiculous approaches with emitting MSIL at runtime).