I was using EF 4.x database-first approach. I have the edmx file and it generated the C# class that derived from EntityObject. I have an ASP.NET MVC 4 application that uses the generated class as model. The client validation that validates the required fields worked fine.
Now I moved to EF 5 and used the DbContext generator, it generates the POCO C# class. I found that the required field validation no longer works in EF 5.
I think the problem is that in EF 4.x EntityObject generator, the generated class has [EdmScalarPropertyAttribute(EntityKeyProperty=false, IsNullable=false)] attribute. However in the EF 5.x POCO class, no data annotation attributes are generated. So the required field information is lost.
So my questions are:
Why does the EF 5.x DbContext generator not generate
[Required] annotations from the edmx file?
Where is the right place to
put these data annotations? Should I modify the .tt file to generate
the [Required] attribute? Or manually write a [MetadataType] partial
class and define data annotation attributes in a separate
class?
1) I don't know why. I just know that Db-first approach doesn't add any data annotations to properties.
2) Indeed creating a separate partial class! Here is an example. Because EF will overwrite and regenerate all POCO classes every time you update your model, any changes (also data annotations) to those classes will be lost...
Perhaps you can find this link useful.
EF Validation
Simply add Metadata class with the required validation:
[MetadataType(typeof(UserMetadata))
public partial class User
{
...
}
public class UserMetadata
{
[UserValidate("State")]
public string State;
// etc.
}
hope this can help
Related
I am using Entity Framework in a Web API project. I have created my classes and models from an existing Database (MySQL), so I basically used the EF DbContextGenerator to generate my classes from my EDMX model.
Read operations are working fine, but I am now at the point where I want to start adding functionality to add records to the database. I want the id for entities to be automatically assigned by the database.
It seems like when you are following a code-first approach, one simply needs to specify:
[DatabaseGenerated(DatabaseGeneratedOption.Identity)]
public int Id { get; set; }
In the class definition for the Id property. So I am tempted to simply add the "DatabaseGeneratedOption" to the class file that was generated. However, since I am using a database-first approach and my classes are basically auto-generated for me, I am not supposed to edit the class files as they will get overwritten again should I re-generate the classes again. Where/How do I set the Id value to be generated by the database rather than by the EF code?
It's an option in the properties of a property (o_O) in the edmx designer:
I ran the EF 5.x DbContext Fluent Generator to generate my code first files and mappings. What I would like is to have all the generated classes include a base interface IEntity. I am also thinking about an abstract base class EntityBase with with properties for Id and rowVersion. I am sure a lot of people have done this but i cant seem to find it in my searches
So for example all my entities would look like this
partial class Person : EntityBase, IEntity
thanks
I am far from an expert, so treat this with caution.
You have the right idea, just create a partial class and put the inheritance/interface references in that one.
You don't modify the generated classes at all, that's the beauty of partial classes.
I'm new to Entity Framework and the database first approach. Can anyone please help me?
Here is the case:
I have a clean, ordinary domain class (Person) with only properties. This class is defined in a VS-project that will only contain domain classes, without any reference to Entity Framework or other things that belong in a data access layer.
I also have a database table (tblPerson). I have created an EDMX for it and used DbContext Generator to create POCO-classes for it.
It is important to keep entity framework references separate from the project with the domain class, and I want to use a repository pattern combined with dependency injection.
The question is:
How do I "map" the Entity Framework POCO-class to my existing domain class? They have the same properties. I have read something about proxies, buddy classes and more, but didn't find any good examples.
Please help.
Lets say that the domain model class looks like this (just an example):
public class Person
{
public int Id { get; set; }
public string Name { get; set; }
}
and the database table has the same colums:
Id (int, not null, primary key)
Name (nvarchar(50), not null)
Update:
Ok, I found a solution. I did what Ladislav Mrnka suggested and derived from ObjectContext. Here is a page that describes how it's done: Entity Framework 4.0 – Part4: How to use your own POCO’s
If you want to map your "domain objects" to the EF generated POCO classes, then you can use a mapper such as AutoMapper https://github.com/AutoMapper/AutoMapper/wiki
Ok, I found a solution. I did what Ladislav Mrnka suggested and derived from ObjectContext.
Here is a page that describes how it's done: Entity Framework 4.0 – Part4: How to use your own POCO’s
Starting from an EF 4 entity diagram and using T4 templates one can create POCO classes that can be used inside the Domain Model. The generated code looks like this:
public partial class Product
{
public virtual int Id
{
get;
set;
}
public virtual string Name
{
get;
set;
}
//and so on
}
Is there any elegant approach to add my own code for implementing the properties? for example, the Name setter I would like to be implemented by lowering all the characters. I would like that my code resist to repeated regeneration of the POCO classes from the EF diagram.
This requirement is somewhat similar to adding validation code to the POCO classes. This issue is already solved by creating a separate validation class and linking it to the POCO through the MetadataType attribute. That separate validation class is not overwritten by repeatedly regenerating POCOs from the EF diagram.
Thanks,
Lucian
No there is no easy way to do that. You must not touch generated code because your changes will be deleted after each regeneration. You options are:
Write entities yourselves and don't use generator - you will get full control over entity code
Modify T4 template in generator to either add your direct code (this can be quite hard to generalize) or simply add call to partial methods (you must also declare these methods in generator) in getter and setter and in your partial part of entity class implement partial methods you need.
Using entity framework (EF) as ORM tool in a 3-tier project, I found entity framework generated code as DAL + a little BLL. Since the DAL and BLL are different layers in this scenario and different coders will work on each of them, there is a need for separating each layer as a different project.
The problem is I don't want changing EF generated code and still need an extra project for BLL (I'm aware of EF partial classes and On...Changing() methods but this doesn't make sense of a good separation of concepts to me and also a partial class cannot be implemented in a different project).
I wish EF would generate an interface for each entity and then implement it as the generated code. That way, I could implement those interfaces by my BLL classes. Then making changes to entities in EF designer would lead to automatically changing the interfaces and my BLL would stopped working (doesn't compile any more, since the interface has been changed). Unfortunately EF doesn't supply those interfaces and extracting them from generated code is hard to maintain since any new change to model need extracting them manually again.
Then I thought of wrapping entity framework generated classes with our own BLL classes (deriving BLL classes from EF classes) and add extra BLL logic there (validations, business rules...) and hide underlying methods and properties with BLL equivalents.
// example of a new property which facilitates using an EF object
class EFaccount // EF generated class
{
DateTime CreationDate { get; set; }
DateTime ExpiranDate { get; set; }
}
class BLLaccount : EFaccount // BLL class
{
new DateTime CreationDate { get; set; }
new DateTime ExpiranDate { get; set; }
// Total age in days as a new property. Storing this, in dbase cause unnecessary redundancy
int Days { get { return (ExpirationDate - CreationDate).TotalDays; } }
}
Since BLL classes are derived from their equivalent EF classes, I need casting from and to a base class which is not allowed.
In my case if I'm casting from a EF to BLL it means object is coming from dbase and extra properties can easily be calculated from base class but compiler doesn't allow casting from base. And if I'm casting from BLL to EF it means object is gonna to be stored in dbase so extra properties could be throw away but compiler doesn't allow casting to base.
What do you suggest ?
The suggestion is:
Use Entity framework 4
Use Entity Objects or preferably POCO
Use Entity Objects or POCO T4 template
Modify T4 template to add additional features for you - generating and implementing interface based on entity properties should be possible.
Argument that you don't want extra codings is ridiculous. You have already proved that with generated code you need a lot of extra codings and you have a lot of additional complications. Generated doesn't mean good. It is not easy to work with generated code if you can't modify its generation (this is possible only if you write your own custom tool for code generation). So here is clear advantage of T4 templates.