What is the best practice for implementing IDataErrorInfo for an entity class. A class that is associated with a table or view.
I have a View that binds to a record from a Task entity class and need to validate the data before it is saved to the SQL CE database. Need to know the best way to implement IDataErrorInfo in this case. I assume just do it on the Task entity class, but want to make sure. Since I have many entity classes that will need validation.
Are you using autogenerated entities? In such case the usual practice is creating second file in the same project where entity is defined and create its second partial part:
public partial Task : IDataErrorInfo
{
...
}
The reason why the interface is implemented in another partial part is that the initial part is autogenerated by some API (Linq-to-sql, EF, etc) and that API can regenerate the code each time you do some changes. That regeneration would delete your changes but if you place them to your own partial part changes will not be deleted.
Related
I want to add attributes on properties inside my model class. But I know if I create new changes in database and update my model the attributes added will be removed. So my question is can I manipulate the model class into a POCO and reference the POCO instead of using EF model class when I do IQueryables.
public IQueryable<UserAccount> GetUserAccounts()
{
return Entity.UserAccounts;
}
UserAccount is an auto generated template model class which was created by EF. Can I have my own model to have data annotations ?
Hy,
The best approach is that you keep the autogenerated class as it is, which makes it more clean and extend class with a partial class containing the extra properties you want.
In a LINQ to SQL class you get the option to View Code of any entity you drag in the design surface. This creates a Partial Class.
Lets say we have an Employee Entity and I create a partial class Employee. What can I use that partial class for? Is it to add Employee methods such as DoWork()?
Do I need to declare any variables that are in the table? (In case of Employee: Name, Surname etc) If so, how do I make the connection between the data present in the Employee record to the class?
partial class is used in EF in order to allow you to make changes and additions to entity classes in a file that is not auto generated. Changes in and auto-generated file might be overridden when updating db context. The use of your own files which extend the partials defined in the auto-generated files prevents that. this also allows you to add implementation to partial methods defined in that partial class, most typically event handlers.
using a partial class in the same name space is very much similar to work inside the other part of class it extends, and it simply allows you to write one class in more than one file. for more information:
https://msdn.microsoft.com/en-us/library/wa80x488.aspx
I have created an entity data model and generated a database from it.
One of the entities is called Template.
Created partial classes to extend the functionality of Template works fine.
If I create a new class and try to derive from Template, I get a runtime exception upon instantiating:
Mapping and metadata information could not be found for EntityType 'Template001'.
How can I work around this? I definitely need to inherit from the EF classes.
EDIT
Does not seem possible. If that is the case, what would be the best way to implement the following requirement: The template entity stores information about templates that each have their own code to execute. That is why I was trying to derive from the entity in the first place.
It is not supported. You cannot derive a new type from entity and use it instead of the mapped entity type for persistence. If you want to have derived class from entity you must use mapped inheritance where every child is also mapped to the database.
Why do you need to inherit from entity class first of all? If you want to add some simple behavior, use partial class.
Update: Based on comments, it appears that there is possibility that behavior will be extended over the time. In this case, I would recommend using composition/aggregation, not inheritance. Let the classes that need to be extended have an entity as a field. In Raheel's scenario, it would be a class called TemplateLogic with field/property of type Template.
i have some questions of how to use the Entity Framework in an enterprise application.
First of all, i work with ADO.NET for many years now and i use objects to reflect the data that i get from the database provider.
Every time i want to change something or insert something into the database.
I just call a Save() method and get the job done.
Every object has a DatabaseManager that manage the queries to the DataAccess layer.
For example
public class Article{
public int ID{get;set;}
public string Title{get;set;}
.....
public bool Save(){
if(this.ID == -1){
return new ArticleDatabaseManager().InsertArticle(this);
}else{
return new ArticleDatabaseManager().UpdateArticle(this);
}
}
}
public ArticleDatabaseManager : DatabaseManager
{
...ADO.NET code
}
I don't know if i have to use the same architectur or change all the way i use this objects in my application.
I thought if i create something like the above i can do something like this :
public class Article{
public int ID{get;set;}
public string Title{get;set;}
.....
public bool Save(){
if(this.ID == -1){
return new ArticleDatabaseManager().InsertArticle(this);
}else{
return new ArticleDatabaseManager().UpdateArticle(this);
}
}
}
In the Each DatabaseManager implements some Link To Entities or even EntitySQL to do the same job like the old DatabaseManager does.
Fill the Business models with the values that i from the Entity Objects.
Then i could work with the Business as before and just any time i want to do some changes i communicate via EntityFramework to the Database.
Sould i implement something like the above?
Sould i just inherit the previous business objects to the entity objects?
EX :
public class Article : ArticleEntity
{
//some properties for validation etc
}
Sould i use something completely different?
I Just Don't knwo:/
I have no experience with other ORM. Just mine hand written "ORM" System.
Thank you very much.
I'm sorry for my lack of English and i know that i ask too much in a single question...
But moving from one technology to an other for a dinosaur like me is like i change Country:/
Did you at least try to use some EF tutorial? If not it is time to do that because we cannot explain you everything about EF in single answer (even in multiple - that is not purpose of SO to replace tutorials and learning materials). That should give you pretty clear answer about all your stuff related to your database managers.
In general what you did till know is very close to Active record pattern. If your objects also has static methods used to retrieve object from database it is Active record pattern. When using EF you usually don't use this pattern and you don't need any database manager. EF is build around class which is called context and this context works as your database manager for all entities you are using. It is possible to add saving and retrieval methods to entities but because it breaks separation of concerns and it makes your entities heavily dependent on EF and persistence (trend is to make them completely independent = POCO) it is usually not used.
Don't derive any custom class from entity. EF will not be able to use your derived type. Use entity mapped in EF as your class and add all custom properties and methods directly to this class (you can even create that class from scratch if you don't want to use code generators). In case of generated entities you can add custom code in partial classes. If you don't use EF entity as your object you will have to manually handle conversion from one to other (or use some tool like AutoMapper).
EF is not able to work with XML column - it will handle it as string. Especially if you plan to use these data for some ordering or filtering and if they have fixed structure you should model them as separate tables / entities. If it is really just structured content (with dynamic structure) you can use it as XML string.
I'm new to EF so please excuse me if this is a noob question.
Basically, we have a EF model set up using Model First for our 'platform' project and is shared across many applications which we build on top of this platform. In some of these applications we want to extend the classes to include additional properties without changing the model in the platform. Is this possible with EF 4 and how would I be able to do it without modifying the .edmx file?
I notice that the generated classes are all partial so potentially I could create a new partial class with the same name to include the new properties but is there any mappings that need to be taken care of?
p.s. under normal circumstances I'd have preferred to use inheritance and create a new class to hold the new properties instead but again, I don't know how to do that with EF.. any enlightenment here will be much appreciated!
Many thanks,
You cannot use inheritance because once entity is loaded from the data source EF will not know about inheritance and because of that it will instantiate base type without your properties instead of derived type with your properties. Any inheritance must be mapped in EDMX if EF have to work with it.
Using partial class will solve your problem but:
All parts of partial class must be defined in the same assembly
Properties from your partial part are not persisted to the database
Properties from your partial part cannot be used in linq-to-entities queries
EF generates partial classes. So to extend MyEntity, create a MyEntity.cs file with
partial class MyEntity
{
public string MyExtraProperty {get;set;}
}
edit: in the same namespace as your generated entities
I agree with adding additional properties to partial class of your entities (as you and Kaido said).
This way you can freely add the properties you want, without modifying generated classes and if you generate your model again (or update it from DB), your partial class is not modified.
In my opinion, adding properties to partial classes of generated entities is the way to go.