What do the people mean when talking of the plurality naming "problem" in context of Entity Framework?
From http://www.cnblogs.com/zjz008/archive/2010/06/03/1750442.html (re: Entity Framework 4.0 Features)...
Plurality Naming
One of the big complaints in the first
version of the Entity Framework was
how naming conventions were applied to
EDM objects such as entities and
navigation properties when using the
model wizards.
The first version of
the Entity Framework gave the Entity
Name and the Entity Set Name the same
name. There was no attempt to
singularize or pluralize names when
generating a model from a database.
The problem is that this caused some
confusion when referencing the
database table or EntityType in code.
For example, if your database has a
table called Employees, then you will
also get an EntityType called
Employees as well. This causes
confusion about whether you are
referencing the table or the
EntityType, such as in the code
fragment below.
Customers customer = new Customers();
Luckily, this issue
has been addressed. The model wizards,
both the Entity Data Model and Update
Model Wizards, now provide the option
of using singular or plural forms of
names for entities, entity sets, and
navigation properties.
The goal of
this change was to make the
application code much easier to read
and avoid a lot of the confusion
between object names.
It revolves around the fact that database objects named in certain ways will lead to either incorrect pluralization or singularization. A good example of this is illustrated by this Microsoft Connect issue.
In this example, database objects end in "Status" are incorrectly singularized as "Statu", instead of being treated as a singularization that would be pluralized as "Statuses".
It is annoying, but I wouldn't consider it to be widespread enough to deter a person from using EF.
Related
So, I'm using EF DbContexts in the following way. One AppDbContext is an abstract class derived from DbContext, it contains my DbSets and is used as a type to inject into services. Its "implementation" is like AppDbContextMySql, which is self-explanatory - it's derived from AppDbContext and handles the connection to the actual DB. There can be several such abstract/implementation pairs to separate the data tables, but usually, all of them point to the same actual DB instance.
Then I need to migrate it all, so I add a MigrationDbContext implementing all the datasets and all the entity configurations needed, namely composite primary keys which can only be configured in OnModelCreating override.
The question is, if I already have the data model configuration in MigrationDbContext, have applied the migration successfully to the DB, and it's DB's job to handle keys and indexes anyway, do I need to have the model configuration in my actually consumed AppDbContext or AppDbContextMySql? In other words, is the model only used to generate migration scripts, or is it also needed at runtime to help EF handle the data in any way?
The short answer is yes, the model is definitely needed in all the cases.
Generating migrations from it is just one of the possible usages, and for sure not the primary - migrations are optional feature which may not be used at all.
The primary purpose of the model is to provide the mappings between the data (objects, properties, navigations) and the storage (database tables, columns and relationships). It is basically the M part of the ORM (Object Relational Mapper) what EF Core is.
It controls all EF Core runtime behaviors - LINQ queries, change tracking, CUD etc. Like what is the associated table/column name, what is the PK/FK property/column, what is the cascade delete behavior, what is the cardinality of the relationship and many others.
The way you asked the question makes me think you are assuming that the model is used just for migrations while at runtime EF Core takes that metadata information from the actual database. That's not the case. For EF Core the database is whatever you told them in the model configuration. Whether the physical database is in sync (correctly mapped) is not checked at all. That's why people start getting errors for non exiting columns in their queries when they screw-up some fluent configuration, or more importantly - do not include such.
Which is the main drawback of using separate (a.k.a. "bounded") contexts for a single database. Because having a DbSet type property in the derived context is not the only way the entity is included in the model. In fact typed DbSet properties are just for convenience and are nothing more than shortcut to the DbContext.Set<T>() method. A common (a sort of hidden) method of including entity in the model is when it is referred (either directly or via collection) by another already included entity. And all that recursively.
And when the entity is included in the model, it needs the associated fluent configuration regardless of the concrete context class. Same for referenced entities, and their references etc.
So I don't really see the benefits of "bounded" context classes - they probably work for simple self containing object set with no relations to other (and vice versa), but can easily be broken by this automatic entity inclusion mechanism.
For reference, see Including types in the model and Creating and configuring a model.
I am using Oracle and LightSpeed Orm and generating model from database.
It seems there is an issue while creating tables that are both plural and singular.
I am getting an error Error 2 Ambiguous moniker '/Ecom/ClaimType' encountered. It is used for both 'ClaimType' and 'ClaimType'.
In this specific instance it's tables CLAIM_TYPE and CLAIM_TYPES that get same (ClaimType) entity generated.
How do I generate two different entities for these?
This came back from lightspeed support:
You will need to split this into two separate model files. We require
entities to be uniquely named in a single model.
J.
(Which imho is ridiculous solution)
Having all my prior Entity Framework experience with 4.1 and a Database First approach, I've just dived into Entity Framework 6.1.2 and Code First from Database.
I have generated my context and entities without a problem but I want to customize the way that EF generates the entities; I want the entities to go from their database name of TABLE_NAME to an entity name of TableName.
I've followed the instructions here and installed the CSharp Code Templates.
I've also found a couple of examples for applying Pascal Case naming (e.g. here) but can't figure out a way to apply the techniques to the NuGet CodeTemplates to cover all scenarios (e.g. I can apply pascal case to simple properties and even NavigationProperties but I can't do it when MethodChain is used in Context.cs.t4 for relationships in OnModelCreating)
There's a similar sort of question here but it applies to EF6 Power Tools which doesn't quite match the scenario now that the Code First from Database functionality is consolidated in EF6.
Am I missing something blindingly obvious? I just want to save myself updating hundreds of entity names after using Code First from Database.
Refactor all your entities to PascalCase then map them like this:
modelBuilder.Entity<TableName>().ToTable("TABLE_NAME");
I am moving my first steps in the Entity Framework 4.0, and I am currently facing an annoying issue.
The authentication/authorization process of my application is based on the standard ASP.NET membership provider, in other words the database is the well-known ASPNETDB.MDF. In this database there are - amongst others - the tables aspnet_Users and aspnet_Roles, which are linked together by the table aspnet_UsersInRoles.
I generated a new "ADO.NET Entity Data Model", I selected Generate from Database, I provided all the necessary parameters, and the wizard generated for me the relative .EDMX file. I named this "SecurityModel". In the aspnet_User entity I can see there is a navigation property that should retrieve all linked Roles, and viceversa.
At this point I added a new "Domain Service", in my case SecurityDomainService.
When I was asked, I selected the SecurityModel, and all the tables it contains.
Even in this case the wizard generated the SecurityDomainService for me.
Apparently no problems at all. However, I realized that in the entity aspnet_User I have all navigation properties (Membership, Profile, Applications, etc.) but Roles.
I read somewhere that EntityFramework doesnt handle many-to-many relationships. However I can see in my Entity Data Model that an Association exists between aspnet_Roles and aspnet_Users, and it is based on aspnet_UsersInRoles. I can also see in the Data Model designer the "Roles" navigation property in the User entity.
So, my question is why has not this navigation property been generated?
Thanks in advance for all your help.
Cheers,
G.
The problem here is that the aspnet_UsersInRoles table contains only the primary key fields of the tables in the many to many relationship. Entity Framework 'inlines' this table and does not represent it as an entity. Entity Framework handles this fine - it is RIA services that does not support this type of relationship.
Simply adding one extra field to the table will prevent it from being inlined and result in an aspnet_UsersInRoles being generated. This will be supported within RIA Services.
You will need to be careful modifying the aspnet schema to ensure that you do not break any of the stored procedures etc but the addition of a nullable bit column should not cause too much disruption.
We just found an issue like, when a foreign key relationship is broken, there is no way to re-establish the link in the designer.
Any other such known limitations of Entity Framework designer?
Among other things,
You can't map complex types at all. (Update Fixed in EF v4.)
You must map every column of a table in the storage schema.
Generalizing (2), you don't get a lot of control over the storage schema at all. What you mostly see is the client schema and the mapping to the storage schema.
If you delete a type from the diagram, it's difficult to put it back.
I wrote some thoughts about the difference in philosophical approaches between the Entity Framework itself and the designer in this post.
I think that if you intend to do non-trivial/non-default things in the Entity Framework, you should get used to editing the EDMX. Most other ORMs do require editing XML at some point, for what it's worth.