I'm using Entity Framework for the first time. I'm using Code First development with an existing database. Everything is working great but I do not like using the table name as the class name. The database tables do not making for friendly class names in C#. Is it common place that people rename the classes that are auto-generated by EF? Will this cause problems down the line in some capacity that I am not anticipating? FWIW, I'm not worried about future schema changes to the tables.
I Google'd a few times but no one seems to have asked this before. Maybe I should take that as a sign....
You can use either data annotation attributes:
[Table("tblFoo")]
public class YourEntity
{
}
Or fluent api
modelBuilder.Entity<YourEntity>()
.ToTable("tblFoo");
to provide table name which entity maps to.
Related
We've been working for along time using EF Designer from database, so switching to another approach is not an option for us.
Due to a legacy version of our app i need to create relationship between tables on EF level for the current version, so those relationships don't exist in the schema.
I understand that i can do do that using Code First from database approach, but the problem how do i map the fields and make these entities part of the main datacontext which we already extended its functionalities using another partial class.. the main problem now is just mapping the new entities fields
i can't create OnCreatingModel in a new datacontext class since it does exist in the auto generated datacontext class.
to sum up.. is there anyway to use both approaches on the same DAL? taking in mind modifying auto-generated classes is absolutely not an option.
Thanks!
So I have run into a situation where I need to use the Entity Framework (DbContext) with databases whose columns are not known at compile time. Basically I don't have the luxury of hard coding a customTable class to put into the DbSet.
The only thing I can think of for solving this issue is using Reflection.Emit to create a customTable class at run-time based on information I glean by interrogating a database.
I was not able to find any information of solving this issue, but I am very new to working with the Entity Framework so maybe a solution would be more obvious to someone more experienced.
I feel like there should be a cleaner way than using Reflection.Emit to dynamically create a class to feed DbSet.
If I am way off base for the intended use of the Entity Framework that information would be useful as well.
Hi I'm investigating this problem too and I have found what seems like the solution.
http://romiller.com/2012/03/26/dynamically-building-a-model-with-code-first/
tells you how to make a DbContext into which you add a new DbSet using a type as a parameter. You can create this type using the Dynamic Linq Library:
http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx
It has a method called CreateClass which will allow you to dynamically build a POCO class definition from a list of field names and load it, you can then create a DbSet using the new type you have created.
You can then get a non-generic DbSet from your updated DbContext using
db.Set(type)
where 'type' is a variable holding your new type. This can be worked on using the linq predicates in the dynamic linq library.
Incidentally, my application is for a CMS where new modules can add fields to the core data table for the CMS, and I don't want to use DI as its too inflexible as no given module will be able to provide a type which has all the fields it needs and all the other unknown modules might also need.
James
Im currently working in a team that uses EF as the ORM of choice.
We have a common project that contains many EDMX files.
The reason for this is to keep the EDMX files small and manageable while also allowing them to focus on a conceptual set of tables on the database.
Eg
Orders.edmx
Users.edmx
Trades.edmx
These all point to a different set of tables on the same db.
I now need to add the user table to the Trade.edmx file. Since the user table is already in the user.edmx file, this creates the same User type twice under a different namespace which means I would need 2 UserRepository objects.
Common.data.trade.User
Common.data.users.User
Is there a way of avoiding 2 repository objects for the same table?
Any suggestions would be greatly appreciated
If you are using POCO generator you can update template for Trades.edmx to not generate new User class and its context template to use User class from Users namespace. EF matches POCO classes with entities in designer only by the class name (namespace is omitted) so it will work.
The disadvantage is that you have User entity in two mapping files and you must update it in both files or your application throw exception at runtime.
The reason for this problem is your architecture - at the beginning you wanted separated models but know you want to combine entities from different models. Those are contradicting requirements. Either use separated model where Trade knows only userID without any navigation property (like if it is defined in another database) or move all entities to single EDMX to support your new requirements.
I am looking at using some kind of Data Generation technology for my next project and was curious about the ADO.NET Entity Framework using Visual Studio 2010. I am new to the entity framework so please be gentle.
My preference for class naming has always been camel case. For example CustomerSite.
My preference for database naming has always been lowercase with underscores. For example customer_site. This seems to be the norm over the last decade where I have worked with database administrators from many companies which is why I adopted this technique.
Using the entity framework to generate my classes, it always uses the table name, so my class name becomes customer_site. Which I hate.
I am mid-coding through a prototype, where the database has many tables (say around 40). At present, I have been working on my own Data Model, but I am sick of hand-coding fields and properties. It is a VB.NET WinForm application with standard CRUD for entities with vareious bells and whistles on top.
Is it possible to make the entity framework class generator use the naming convention of what I want or not? Or do I need to change my database naming conventions? Or just go with what the entity framework class generator gives me - customer_site as class name.
Any thoughts?
Thanks,
Andez
As mentioned in this question, you can set up mapping between your entities and your tables which enables you to have different table and class names. You can do this by overriding DbContext.OnModelCreating, or by using the TableAttribute.
I'd say if you're comfortable doing it you should stick to different naming conventions for your tables and entities.
I'm new to the MVC way of developing applications and for the most part am enjoying. One thing I'm a bit confused about is the use of the Entity Framework. The EF usually (at least in my experience) defines multiple tables and relationships through the .edmx table. A couple of questions:
Why would I define a separate class file for a specific table if EF is building all of the classes that I need in the background?
From some of the validation approaches that I've seen, they want to define validation logic in the class related to a model for a table. If I'm using EF, will I have a .cs file describing the model and a .edmx describing that same table (in addition to its associated tables)?
If yes, how do you connect the .cs file to the .edmx definition so that CRUD flows easily from the EF?
Sorry if these seem like easy questions but I'm just trying to get my head wrapped around these fundamental concepts. Too many examples out there use only a single table where in my business, I NEVER write an application that uses a single table. There are always multiple tables in relation to each other with foreign keys. Thanks for your prompt responses.
For a tutorial that shows the use of partial classes -- in a Web Forms application but for MVC the same technique would be used -- see Adding Metadata to the Data Model in this tutorial:
http://www.asp.net/web-forms/tutorials/getting-started-with-ef/the-entity-framework-and-aspnet-getting-started-part-8
From your comment "The EF usually (at least in my experience) defines multiple tables and relationships through the .edmx table." it sounds like you are familiar only with Database First and Model First -- for an introduction to Code First and an explanation of the differences, followed by a series of tutorials with an MVC example using Code First, see this tutorial:
http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/creating-an-entity-framework-data-model-for-an-asp-net-mvc-application
Good questions, Darryl. Here are my responses to your bullet points:
Defining separate model classes that match the data models that EF creates is generally a good idea for the simple sake of separating your data access "stuff" from your business model objects that will get used throughout your app. Some people don't like this approach because it creates some amount of overhead when it comes to mapping your entities to POCOs but, if you use a tool such as AutoMapper, the overhead is minimal. The benefit lies in you creating a layer of separation between you and your (likely) evolving data model.
You could define validation logic in a buddy class (just a partial class that sits along-side your entity) but that would mean that you would be using that entity across your app and some would debate that that isn't the best idea. The alternative method, as mentioned above, is to create your own POCOs to mirror the entities that EF creates and place your validation attributes on the POCOs.
I mentioned this in the previous item but the way to do this would be to define buddy classes. Give EF buddy classes a Google and you should find plenty of examples on how to do that.
Just to add to all of this, if you choose to create POCO classes that mirror your EF entities, tools like AutoMapper can handle fairly complex relationships when it comes to mapping classes. So, if you have foreign key relationships in your data model, AutoMapper can understand that and map your POCO classes accordingly (i.e.: You have an entity that has a 1-to-many relationship and a POCO with a list of objects to mirror that relationship.)
I hope some of that helps...