I have used EF to generate classes for my database tables:
public partial class Course
{
public Course()
{
this.People = new HashSet<People>();
}
public int ID { get; set; }
public string Name { get; set; }
public virtual ICollection<Person> People { get; private set; }
}
public partial class Person
{
public int ID { get; set; }
public string Name { get; set; }
public virtual Course Course { get; set; }
}
As you can see each course has a collection of people. I created a second partial class so my code does not get cleared when i refresh the EF diagram. My question is how can i clear the list of people from within the course object?
I tried:
public partial class Course
{
public void ResetCourse()
{
this.People.Clear();
}
}
But i get this error:
The operation failed: The relationship could not be changed because one or more of the foreign-key properties is non-nullable. When a change is made to a relationship, the related foreign-key property is set to a null value. If the foreign-key does not support null values, a new relationship must be defined, the foreign-key property must be assigned another non-null value, or the unrelated object must be deleted.
which is apparently caused because EF is not actually deleting the person object just removing the relationship between the two which SQL throws out because it cannot have a null key.
Apparently i should use something like
context.DeleteObject(person)
However inside the course object it has no reference to the context and i wanted to keep the code inside the object to keep it simple of the ui code.
Instead of using Course classes to manage database operations; it is better to employ repository and unitofwork patterns while working with entity framework. Otherwise, your entities always carries context on them; which will lead to some problems.
Just create a Course repository with context as a parameter and employ the database operations in the repository instead of the entity itself. Refer to:
Unit of Work and repository patterns
Related
I am using EF Core and I have a scenario where the user can create a custom field and then creates options for that custom fields.
public class CustomField : Entity<long>
{
[Required]
public string Name { get; private set; }
public bool IsRequired { get; private set; }
public List<CustomFieldOption> customFieldOptions;
public virtual IReadOnlyCollection<CustomFieldOption> CustomFieldOptions => customFieldOptions;
protected CustomField()
{
}
public CustomField(long id, string name, bool isRequired, List<CustomFieldOption> customFieldOptions)
{
Id = id;
Name = name;
IsRequired = isRequired;
this.customFieldOptions = customFieldOptions;
}
}
public class CustomFieldOption : Entity<long>
{
[Required]
[MaxLength(256)]
public string Text { get; private set; }
protected CustomFieldOption()
{
}
public CustomFieldOption(string text)
{
Text = text;
}
}
public class Client : Entity<long>
{
public Name Name { get; set; }
private List<ClientCustomFieldOptionValue> customFieldOptionValues { get; set; } = new List<ClientCustomFieldOptionValue>();
public IReadOnlyCollection<ClientCustomFieldOptionValue> CustomFieldOptionValues => customFieldOptionValues;
public Client(Name name)
{
}
public Result AddCustomFieldOptionValues(List<ClientCustomFieldOptionValue> values)
{
return Result.Success();
}
public Result RemoveCustomFieldOptionValues(List<ClientCustomFieldOptionValue> values)
{
return Result.Success();
}
}
public class ClientCustomFieldOptionValue
{
public CustomFieldOption CustomFieldOption { get; private set; }
protected CustomFieldOptionValue()
{
}
public ClientCustomFieldOptionValue(CustomFieldOption customFieldOption)
{
CustomFieldOption = customFieldOption;
}
}
CustomFieldOption seems to be a Value Object as the text it holds is something that doesn't need an Id. But then in terms of store persistency needs an Id to be stored in database on a different table where it can be queries by Id etc...
I am not sure if I shall add it as an Entity because ValueObjects do not have Id.
One other problem I have is validation. If it is an Entity how can I validate Text property. I know validation on constructor is a bad idea. If I validate it in the ApplicationLayer then wherever I create a new object I have to validate that is not empty and the length.
If I forget to add validation in one of the application services and pass null Text then I create an inconsistent state.
Update #1
A Client can select one or many options of a custom field. I suppose these needed to be stored on a separate table ClientCustomFieldOptionValue. In that case is this an entity or a valueobject? And what about CustomFieldOption. Does it become an Entity? I am quite confused when to use Entity or ValueObjects
Try not to think of persistency details while designing domain model.
According to your description, CustomFieldOption expresses an individual property with no business relations to any other structure, thus:
it should not hold a business identifier
it should encapsulate its own validations
Meaning it fits the concept of a value-object (validation inside ctor).
When it comes to persistency, your repository model should be capable of storing CustomFieldOption objects in a child table (with DB identifier) referencing the parent table (CustomField objects)
On the query side, repository should be capable of aggregating data from these two tables into a single CustomField entity.
(How exactly you implement such DB capabilities depends on the ORM you choose to work with, EF in your case)
Just one observation, if you will use Ef Core and the containing entity has a one to many relationship with the value objects, you will have this limitation:
Owned Entity types, Ef Core
Owned types need a primary key. If there are no good candidates properties on the .NET type, EF Core can try to create one. However, when owned types are defined through a collection, it isn't enough to just create a shadow property to act as both the foreign key into the owner and the primary key of the owned instance
If you are mapping your entities and value objects using DbContext, you usually define an owned entity type for a value object or use a record type.
For owned entities, this creates a column in your table like this: EntityName_ValueObject (i.e. Person_Address) but this works for a single value object not a collection when you don't know in advance the number of items in the collection.
It is correct that you should not concern with persistence when designing your domain, but is also correct to think that having a value object with an identity does not make sense.
Most important, you should be aware of this potential issue early on.
I'm having a hard time defining the relations I want using EF Core(1 to many) .
E.G:
I am an entity of Task and Employee , each task is given by an employee and also is appointed to an employee . I've created the Task class as follow:
public class Task
{
public int TaskId { get; set; }
[ForeignKey("RequestedBy")]
[Required]
public int RequestedById { get; set; }
[Required]
[ForeignKey("TaskedTo")]
public int TaskedToId { get; set; }
public virtual Employee RequestedBy { get; set; }
public virtual Employee TaskedTo { get; set; }
}
I think I've done it correctly, but I have a problem with my Employee class. Usually (When there's only one join) I would simply create virtual collection of Task Property in Employee .. but what am I supposed to do now ? Is this enough to set the relation or should I add virtual properties for these two tasks?
And another thing, when I have an owned entity, with 1-Many relation , is it enough to add the property in the owner entity, and do nothing in the owned one? Or do I have to specify the [Owned] Annotation?
The issue is that you have two one-to-many relationships between the same two entities. For the Employee class you would need two collections, one for each relationship. Additionally, you'll need to use the InverseProperty attribute to tell EF which foreign key goes with which collection:
public class Employee
{
...
[InverseProperty(nameof(Task.RequestedBy))]
public ICollection<Task> RequestedTasks { get; set; }
[InverseProperty(nameof(Task.TaskedTo))]
public ICollection<Task> AssignedTasks { get; set; }
}
You don't need virtual. That's to enable lazy-loading. For the lazy-loading functionality, EF creates a dynamic proxy class that inherits from your entity and overrides the getter on the navigation property. The virtual keyword is required in C# to allow a class member to be overridden.
Also, the Owned attribute is for value objects. It's a way of having a related class whose properties are literally mapped onto the same table or if given its own table, inherently tied to the entity that "owns" it, such that you access that data through the entity, not separately. Neither of which applies here.
Finally, you should reconsider the name Task for this class. .NET already has a Task class, and it's used very frequently. If you name your class Task as well, you'll be having to specify namespaces virtually every time you use either one, which is a pain.
Background
I have a class that looks more or less like this:
public class MyClass
{
[Id]
public long Id { get; set; }
public string MyProperty { get; set; }
public bool MyBoolean { get; set; }
public string AnotherProperty { get; set; }
public MyClass ChildOne { get; set; }
public MyClass ChildTwo { get; set; }
}
I will need to use a stored procedure to load a set of records, but that's ok as long as the structure itself is correct.
For any instance of MyClass, one or both of the children can be null. Any instance of MyClass can be used in a parent class - but the child itself doesn't need to know about this relationship, and a child can be used by any number of parents.
Problem
With this structure, I get the following error when creating a new migration:
Unable to determine the principal end of an association between the
types 'MyClass' and 'MyClass'. The principal end of this association
must be explicitly configured using either the relationship fluent API
or data annotations.
This error makes sense - when given a structure of an object with a foreign key to itself, I am not surprised that EF has a hard time determining the principal end. I'm not sure how to fix this, though.
I've tried some different Fluent mappings:
modelBuilder.Entity<MyClass>().HasOptional(x => x.ChildOne).WithOptionalPrincipal(x => x.ChildOne);
modelBuilder.Entity<MyClass>().HasOptional(x => x.ChildOne).WithOptionalDependent(x => x.ChildOne);
modelBuilder.Entity<MyClass>().HasOptional(x => x.ChildOne);
(Note: I didn't try these concurrently - I did one at a time & duplicated it for ChildTwo.)
I was able to get a migration to work by adding a ChildThree property to MyClass, but that doesn't make sense and isn't a useful property; it just creates another foreign key on the table but this isn't needed in my model.
So, in summary:
How do I get this structure to work the way I want? I think the secret is in some Fluent mapping voodoo but I'm very unfamiliar with that library and I don't know how to get that to work.
Why does adding a third (unneeded, unwanted) property fix everything and allow the migration to scaffold?
Your fluent mapping is totally wrong.
You should do something like this:
modelBuilder.Entity<MyClass>().HasOptional(p => p.ChildOne).WithOptionalDependent();
modelBuilder.Entity<MyClass>().HasOptional(p => p.ChildTwo).WithOptionalDependent();
This is a long one.
So, I have a model and a viewmodel that I'm updating from an AJAX request. Web API controller receives the viewmodel, which I then update the existing model using AutoMapper like below:
private User updateUser(UserViewModel entityVm)
{
User existingEntity = db.Users.Find(entityVm.Id);
db.Entry(existingEntity).Collection(x => x.UserPreferences).Load();
Mapper.Map<UserViewModel, User>(entityVm, existingEntity);
db.Entry(existingEntity).State = EntityState.Modified;
try
{
db.SaveChanges();
}
catch
{
throw new DbUpdateException();
}
return existingEntity;
}
I have automapper configured like so for the User -> UserViewModel (and back) mapping.
Mapper.CreateMap<User, UserViewModel>().ReverseMap();
(Note that explicitly setting the opposite map and omitting the ReverseMap exhibits the same behavior)
I'm having an issue with a member of the Model/ViewModel that is an ICollection of a different object:
[DataContract]
public class UserViewModel
{
...
[DataMember]
public virtual ICollection<UserPreferenceViewModel> UserPreferences { get; set; }
}
The corresponding model is like such:
public class User
{
...
public virtual ICollection<UserPreference> UserPreferences { get; set; }
}
The Problem:
Every property of the User and UserViewModel classes maps correctly, except for the ICollections of UserPreferences/UserPreferenceViewModels shown above. When these collections map from the ViewModel to the Model, rather than map properties, a new instance of a UserPreference object is created from the ViewModel, rather than update the existing object with the ViewModel properties.
Model:
public class UserPreference
{
[Key]
public int Id { get; set; }
public DateTime DateCreated { get; set; }
[ForeignKey("CreatedBy")]
public int? CreatedBy_Id { get; set; }
public User CreatedBy { get; set; }
[ForeignKey("User")]
public int User_Id { get; set; }
public User User { get; set; }
[MaxLength(50)]
public string Key { get; set; }
public string Value { get; set; }
}
And the corresponding ViewModel
public class UserPreferenceViewModel
{
[DataMember]
public int Id { get; set; }
[DataMember]
[MaxLength(50)]
public string Key { get; set; }
[DataMember]
public string Value { get; set; }
}
And automapper configuration:
Mapper.CreateMap<UserPreference, UserPreferenceViewModel>().ReverseMap();
//also tried explicitly stating map with ignore attributes like so(to no avail):
Mapper.CreateMap<UserPreferenceViewModel, UserPreference>().ForMember(dest => dest.DateCreated, opts => opts.Ignore());
When mapping a UserViewModel entity to a User, the ICollection of UserPreferenceViewModels is also mapped the User's ICollection of UserPreferences, as it should.
However, when this occurs, the individual UserPreference object's properties such as "DateCreated", "CreatedBy_Id", and "User_Id" get nulled as if a new object is created rather than the individual properties being copied.
This is further shown as evidence as when mapping a UserViewModel that has only 1 UserPreference object in the collection, when inspecting the DbContext, there are two local UserPreference objects after the map statement. One that appears to be a new object created from the ViewModel, and one that is the original from the existing model.
How can I make automapper update an existing Model's collection;s members, rather than instantiate new members from the ViewModel's collection? What am I doing wrong here?
Screenshots to demonstrate before/after Mapper.Map()
This is a limitation of AutoMapper as far as I'm aware. It's helpful to keep in mind that while the library is popularly used to map to/from view models and entities, it's a generic library for mapping any class to any other class, and as such, doesn't take into account all the eccentricities of an ORM like Entity Framework.
So, here's the explanation of what's happening. When you map a collection to another collection with AutoMapper, you are literally mapping the collection, not the values from the items in that collection to items in a similar collection. In retrospect, this makes sense because AutoMapper has no reliable and independent way to ascertain how it should line up one individual item in a collection to another: by id? which property is the id? maybe the names should match?
So, what's happening is that the original collection on your entity is entirely replaced with a brand new collection composed of brand new item instances. In many situations, this wouldn't be a problem, but when you combine that with the change tracking in Entity Framework, you've now signaled that the entire original collection should be removed and replaced with a brand new set of entities. Obviously, that's not what you want.
So, how to solve this? Well, unfortunately, it's a bit of a pain. The first step is to tell AutoMapper to ignore the collection completely when mapping:
Mapper.CreateMap<User, UserViewModel>();
Mapper.CreateMap<UserViewModel, User>()
.ForMember(dest => dest.UserPreferences, opts => opts.Ignore());
Notice that I broke this up into two maps. You don't need to ignore the collection when mapping to your view model. That won't cause any problems because EF isn't tracking that. It only matters when you're mapping back to your entity class.
But, now you're not mapping that collection at all, so how do you get the values back on to the items? Unfortunately, it's a manual process:
foreach (var pref in model.UserPreferences)
{
var existingPref = user.UserPreferences.SingleOrDefault(m => m.Id == pref.Id);
if (existingPref == null) // new item
{
user.UserPreferences.Add(Mapper.Map<UserPreference>(pref));
}
else // existing item
{
Mapper.Map(pref, existingPref);
}
}
In the meantime there exists an AutoMapper Extension for that particular problem:
cfg.AddCollectionMappers();
cfg.CreateMap<S, D>().EqualityComparison((s, d) => s.ID == d.ID);
With AutoMapper.EF6/EFCore you can also auto generate all equality comparisons. Plaese see AutoMapper.Collection AutoMapper.EF6 or AutoMapper.Collection.EFCore
According to the AutoMapper source file that handles all ICollection (among other things) and the ICollection Mapper:
The collection is cleared by a call to Clear() then added again, so as far as I can see there is no way that AutoMapper will be able to automagically do the mapping this time.
I would implement some logic to loop over the collections and AutoMapper.Map the ones that are the same
I'm getting the following error message while trying to delete an item from the db:
The operation failed: The relationship could not be changed because one or more of the foreign-key properties is non-nullable. When a change is made to a relationship, the related foreign-key property is set to a null value. If the foreign-key does not support null values, a new relationship must be defined, the foreign-key property must be assigned another non-null value, or the unrelated object must be deleted.
I've read many topics about this issue, but none of them seem to help (or maybe i didn't understand them very well).
my models are:
public class ARDOperation
{
[Key]
public int ARD { get; set; }
[Required]
public virtual ICollection<Act> Actions { get; set; }
public ARDOperation()
{
this.Actions = new List<Act>();
}
}
public class Act
{
[Key]
[DatabaseGenerated(DatabaseGeneratedOption.Identity)]
public int ARDID { get; set; }
public int ARDOperationId { get; set; }
[ForeignKey("ARDOperationId")]
public virtual ARDOperation ARDOperation { get; set; }
public string Data { get; set; }
[EnumDataType(typeof(ARDState))]
public ARDState State { get; set; }
}
I Also defined a fluent API:
public class ARDOperationDBContext : DbContext
{
public DbSet<ARDOperation> ARDOperation { get; set; }
//public DbSet<Act> Act { get; set; }
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<Act>()
.HasRequired(t => t.ARDOperation)
.WithMany(t => t.Actions)
.HasForeignKey(d => d.ARDOperationId)
.WillCascadeOnDelete(true);
//modelBuilder.Entity<ARDOperation>()
}
The method in controller:
internal void RemoveAction(int ARDID)
{
var op = ARDOperationDB.ARDOperation.Find(ARDID);
if (op != null)
{
//will not remove the "idle" action
if (op.Actions.Count > 1)
{
Act act = op.Actions.ElementAt(1);
op.Actions.Remove(act);
//ARDOperationDB.Entry(op).State = EntityState.Modified;
ARDOperationDB.SaveChanges();
}
}
}
I've tried to define the "ARDOperationId" property as nullable (int?) using code-first approach and i'm not getting any errors this way, but the child's data still remain in the DB.
I think that i'm missing something related to the access to the Act model.
Will appreciate any help,
Yuval.
Take a look at [this answer][1] from an EF guru about the remove method.
EntityCollection.Remove(childEntity) marks the relationship between
parent and childEntity as Deleted. If the childEntity itself is
deleted from the database and what exactly happens when you call
SaveChanges depends on the kind of relationship between the two:
If the relationship is optional, i.e. the foreign key that refers from
the child to the parent in the database allows NULL values, this
foreign will be set to null and if you call SaveChanges this NULL
value for the childEntity will be written to the database (i.e. the
relationship between the two is removed). This happens with a SQL
UPDATE statement. No DELETE statement occurs.
If the relationship is required (the FK doesn't allow NULL values) and
the relationship is not identifying (which means that the foreign key
is not part of the child's (composite) primary key) you have to either
add the child to another parent or you have to explicitly delete the
child (with DeleteObject then). If you don't do any of these a
referential constraint is violated and EF will throw an exception when
you call SaveChanges - the infamous "The relationship could not be
changed because one or more of the foreign-key properties is
non-nullable" exception or similar.
If the relationship is identifying (it's necessarily required then
because any part of the primary key cannot be NULL) EF will mark the
childEntity as Deleted as well. If you call SaveChanges a SQL DELETE
statement will be sent to the database. If no other referential
constraints in the database are violated the entity will be deleted,
otherwise an exception is thrown.
[1]:
Entity Framework .Remove() vs. .DeleteObject()
So i read a bunch of articles on this subject. Chris's response here was really good and helpful for my understanding: Link
But what really helped me was the small code example here: Solution.
The "[Key, ForeignKey("Order"), Column(Order = 1)]" part really did the trick.
Many Thanks!