I am converting from nhibernate to EF 5.0 as I want to see if it will make my life easier(having way too many problems with the Spatial 3rd library)
What is the equivalents for these fluent nhibernate mappings
References
HasMany
HasManyToMany
HasOne
I am using separate files(EntityTypeConfiguration) like I would with nhibernate fluent instead of putting it all with the db context.
There you go: http://msdn.microsoft.com/en-US/data/jj591620
Instead of modelBuilder.Entity() use "this".
BTW. I know you're coming from nHibernate, but much of EF magic comes from conventions. Yeah, you can specified everything if config files, but why not try conventions first? Saying that if you work on some big, huge, finance project then may stick to configs.
Oh, and this may be confusing:
modelBuilder.Entity<OfficeAssignment>()
.HasRequired(t => t.Instructor)
.WithOptional(t => t.OfficeAssignment);
It works like that:
OfficeAssignement has required Instructor, after this call you are at instructor, so instructor has optional OfficeAssignement. I found this confusing when I started with EF
Related
This is the way I can create an „association class“ in MDriven.
Is there an equivalent in Entity Framework (especially EF Core)?
I am aware that this can be done by this:
but this is not really „elegant“, I‘d rather prefer something the first way.
How can the first version be coded (Code-First) in EF.Core (if possible)?
TIA,
Levend
I have built a database using EF Codefirst (In an MVC4 application).
I've since learnt, that an external tool that will access this database has name-length limitations for columns & constraints.
Column names must be <=20 chars
Constraint names muse be <=10 chars
I'm therefor required to change the names of the generated DB constraints. (None of my column names exceed the limitation.)
Can I achieve this without destruction?
Does the migration framework provide the tools I need for such an operation?
As far as i know, Entity framework code first does not use the constraint name in its EntityTypeConfiguration. You should be able to rename the constraint to anything you like and just mention the relationships using the properties of your entities. This is how a configuration normally looks like.
// Relationships
this.HasRequired(t => t.Project)
.WithMany(t => t.ProjectInstances)
.HasForeignKey(d => d.ProjectId);
There is this handy little tool from entity framework team called Entity Framework Power Tools. You can generate the Code first entities and mappings by using that. You can use that tool in some test project and look at the generated code. I am pretty sure you will not have any issues even if you rename your constraints as long as you give the properties correctly.
Does anyone know why LinqPad cannot autogenerate an Entity Framework context object (like it does with Linq-to-SQL)? It seems I have to create an assembly containing an EF context and then reference the assembly in LinqPad. But I don't need to do this with L2S.
Thanks very much.
LINQPad uses LINQ-to-SQL for automatic data contexts because it's lighter and faster. LINQ-to-SQL also generates better SQL in many cases and allows arbitrary functions in the final projection.
It wouldn't be hard, in principle, to write a driver for Entity Framework. The reason it isn't present as an option is lack of demand.
If you wanted, you could implement EF support seamlessly as a third-party driver. The only tricky thing to implement is supporting every version of EF.
Is it possible to auto generate the POCO classes and the mapping with the database defined separately using Fluent API (instead of annotations) for an existing database? Instead of coding all these entity classes manually, I find it easier if they are auto generated and then I can change them as required if the names are not incorrect (plural or singular) or the some of the relationships are not correctly mapped etc. This will save lot of time for me compared to coding all the entity classes and relationships from scratch and I am not that familiar with the fluent API syntax as well.
Yes, i encourage you to use Entity Framework Power Tools CTP1
Reverse Engineer Code First - Generates POCO classes, derived DbContext and Code First mapping for an existing database.
hope this helps
The Power tools are incredibly slow to generate files. It takes over an hour to work on my companies database (has a lot of tables).
Instead take a look at this visual studio extension http://visualstudiogallery.msdn.microsoft.com/ee4fcff9-0c4c-4179-afd9-7a2fb90f5838
It generates cleaner code, WCF serialisation classes, and includes the database default constraints as part of the POCO ctor.
Disclaimer: I should mention that I am the author of this extension
We are about to start using EF as our ORM. We have our own MetaData representing the databse stracture and we will generate whatever we need off of that.
We are wondering whether to use the "old" EDMX approace, or to use the new EDMX free approach (wiht DbSet and DbContext). As we do our own code/edmx generation it seems odd to generate an EDMX and then generate objects and context off of it.
The thing is I don't see much talk about about the EDMX free approach. Is it being used by anyone? Can someone with experience share their impressions? Are there known limitations? Are there pros and cons?
Asher
Are you asking if anybody is using code-first? :) By checking the number of questions in entity-framework-4.1 and code-first and ef-code-first I guess people are using it a lot. There were several questions about code-first x non code-first. Some of I answered:
EF POCO code only VS EF POCO with Entity Data Model
EF Model First or Code First Approach?
EF 4.1 Code-first vs Model/Database-first
Generally there are four approaches:
Model first (database generated from EDMX)
Database first (EDMX generated from database)
Code first (database generated from code mapping)
Database first with code mapping (code mapping manually created for existing database or manually updated mapping generated by EF Power Tools CTP)
Selection of the approach usually depends on the way how you want to develop application (as described in linked answers). It also depends if you want to use ObjectContext API or DbContext API. The former one is usually used with first two approaches (but the secret is it should work with code-first as well) the later one with all of them.
Code first has some limitations - it doesn't support all mapping features EDMX does for example:
Stored procedures mapping (it doesn't mean you cannot execute SP when using code first)
SQL functions mapping
Advanced EDMX features like defining queries, query views, model defined functions
etc.
What I don't understand is why are you trying to combine your code generation tool with EF. Either use your stuff or use EF's stuff. You will avoid complications and incompatibilities.