My original data model has an entity "Game". I have now updated the model to include an entity, "Match", which can refer to multiple games. I wish to add a Match to all of my old Games, and ideally this would be a non-optional relationship.
Currently I am setting Match to be optional, and simply adding a Match to every old Game in application:didFinishLaunching after the model has been updated. This works, but I'm wondering if this is really the best way to do it.
I have tried to follow the tutorial here, but I am getting stuck on the part with "StepOneEntityMigrationPolicy.m". I have created an NSEntityMigrationPolicy subclass and set it in the mapping model. I've tried overriding both createDestinationInstancesForSourceInstance and createRelationshipsForDestinationInstance:, but neither get called.
Is this perhaps because my Source and Destination are both the same (GameToGame)? Also, is there any benefit to doing this via the mapping model rather than as I am doing it now?
I think the simplest and most pragmatic way is what you are doing now, i.e. inserting the necessary new entities "manually" after an update. This is a common way to populate orphaned entities after a model version upgrade and perfectly fine.
Related
I'm trying to improve my design using some DDD concepts. Currently I have 4 simple EF entites as shown in the following image:
There are multiple TaskTemplates each of them storing multiple TasksItemTemplates. The TaskItemTemplates contains various information (description, images, default processing times).
Users can create new concrete Tasks based on a TaskTemplate. In the current implementation, this will also create a TaskItem for every TaskItemTemplate, but in the future it might be possible to select one some relevant TasksItemTemplates.
I wonder how to model this requirement in DDD. The reference from TaskItem to TaskTemplateItem is not allowed, because TaskTemplateItem is not an aggregate root. But without this reference it is not possible to get the properties of the TaskTemplateItem.
Of course I could just drop the reference and copy all properties from TaskTemplateItem to TaskItem, but actually I like the possibility to update TaskItems by updating the TaskTemplateItems.
Update: Expected behaviour on Task(Item)Template updates
It should be possible to edit TaskTemplate and TaskItemTemplate and e.g. fix Typos in Name or Description. I expect these changes to be reflected in the Task/TaskItem.
On the other hand, if the DefaultProcessingTime is modified, this should not change the persisted DueDate of a TaskItem.
In my current Implemenation it is not possible to add/remove TaskItemTemplates to a persisted TaskTemplate, but this would be a nice improvement. How would I implement something likes this? Add another entity TaskTemplateVersion between TaskTemplate and TaskItemTemplate?
Update2: TaskItemTemplateId as ValueObject
After reading Vaughn's slides again, I think with a simple modification, my model is correct according to DDD:
Unfortunately I do not really understand, why this Design is better (is it better?). Okay, there won't be unnecessary db queries for TaskItemTemplates. But on the other side I almost ever need a TaskItemTemplate when working with a TaskItem and therefore everything gets more complicated. I cannot any longer do something like
public string Description
{
get { return this.taskItemTemplate.Description; }
}
Based on the properties that you list beneath TaskItem and TaskItemTemplate I'd say that they should be value objects instead of entities. So if there isn't a reason (based on the information in your question there isn't) to make them entities, change them to immutable value objects.
With that solution, you just create a TaskItem from a TaskItemTemplate by copying its data.
Regarding the update scenario that you describe, it see the following solution:
TaskItems are created from a specific version of the TaskItemTemplate. Record that version with a TaskItem.
The TaskTemplate is responsible for updating its items and keep track of their version.
If a template changes, notify all Tasks that are derived from the template if immediate action is required. If you just want to be able to "pull in" the template changes at a later time (instead of acting when the template changes), you just compare the versions.
To make informed decisions, it is very important that you fully understand the pros and cons of immutability. Only then you will see a benefit in modelling things as value objects. One source on the topic that I find very valuable is Eric Lippert's series on immutability.
Also, the book Implementing DDD by Vaughn Vernon explains the concepts of value objects and entities very well.
I'm trying to start an application and my idea was to rattle off the entities first using the command line and then work on the UI. This is proving trickier than I first thought because under certain circumstances you get a warning saying the generator won't work. It's things like whether it's a OneToMany or a ManyToOne or whether this entity is the owning side of the relationship.
What's the best way around this?
If I can work out the rules then I can maybe decide what order to create things in. My worry is that with a complicated schema there is no order that can work without some warnings and things not working.
My other idea was to generate the entities without relationships first and then edit the json files to add the relationships. Then maybe I can run the generator again on each entity. Not sure if that would work though and I'm not 100% sure of the correct json properties required.
What have other people tried?
Plan your entities and relationships, so that when you create an entity all the entities it depends on have already been created. One way to do this is use a schema designer or just document the entities and put them in the order they need to be created.
Otherwise, as you know, you'll have to manually wire those relationships, or recreate them with the entity generator.
But, even with planning, you're going to have to use a mixture of these methods in the real world. It just depends on how much you've modified the generated code as to which method is the fastest.
Rori's answer is basically what I did but I wanted to provide some extra detail.
First I went through the generator and created every type of relationship to see which ones worked and which ones gave a warning. I was finding that sometimes it worked and sometimes it didn't but it wasn't documented anywhere why.
These relationships always work.
OneToMany
OneToOne (not owner)
ManyToMany (not owner)
These relationships only work when the other entity already exists.
ManyToOne
OneToOne (owner)
ManyToMany (owner)
The reason they don't work is always the same. All of these require a foreign key to be created on the other table which jHipster can't do if it doesn't exist yet. You could of course ignore the warning but I wasn't sure if this meant anything else wouldn't work.
Based on these rules I made a list of my entities and put them into an order that would work without warnings. If an entity had a relationship that may give a warning then I just made sure the other entity was created first.
This seems to have worked. The only thing I've found is that because the generator is a one time thing (you can't use it to modify an entity), you have to know your schema up front and generate the lot in one go.
I am having a bit of trouble implementing the Repository pattern, due to some confusion.
As far as I can tell now, a Repository should behave like an in-memory collection of objects, so if I do say:
$users = new UserRepository(new UserMapper);
$users->findAll();
The Users repository will load and return an array of User entities. Now I can either use them for just reading data, or can update the data on any particular entity, and invoke a save() method on the Repository that will utilize the Mapper to save the loaded entities back to the data source, with the updates that have been applied.
What I am wondering is if that is a correct understanding.
Should the add() method add an entity directly to the data source, or only to the collection within the Repository?
Likewise for remove(); should this method remove an entity from the data source, or only from the Repository.
The confusion stems from the fact that some implementations I have seen in tutorials have both add()/remove() methods, alongside save()/delete() methods. Is that the correct approach?
I've been developing using DDD techniques for around 6 months now and always use the save and delete methods, the save should persist the data to your persistence layer, the delete should remove from your persistence layer.
Saying the above, there is no reason why it shouldnt add to your collection.
p.s check out the dddinphp Google Group, theres an active community purely for these questions
When I set the option 'NSInferMappingModelAutomaticallyOption' to yes, the new model is setup using the old models data. However, it should be using my custom Mapping Model to update specific values.
For some reason it does not use this mapping model and I really need it to as some important data is not moved from one old entity to a new entity.
Any ideas?
I have a CoreData entity X, and controllers for this entity, XController.
Now there's another entity, XGroup, containing a collection of X entities, and a XGroupController.
Now the problem is that XGroupController needs to interact with XController, and it would be nice to just pass XGroupController a XGroup to observe, and then get the XControllers from the X entities.
So the question is: is it a good idea to store a (weak, to avoid retain cycles) reference to a controller in an entity? It just feels a bit "wrong". Is there another design pattern for this?
[Edit] Some more information:
XController/XGroupController are view controllers; and the reason why it felt "wrong" is that the view layer shouldn't be in the model layer. So #TechZen is right with his first paragraph.
However, how would I do that if I don't have that reference?
The way I see is to pass XGroupController all existing XControllers (plus update them when they change), and then when the items in the XGroup change, find the corresponding controllers (by checking if the XControllers property for it's X entity is in the XGroup) and finally talk to the XControllers.
I have to do work again for stuff the model already handles very nicely.
Doesn't it make the model layer kind of pointless if I have to handle groups in the controller layer another time?
The difference that makes in terms of Loc/complexity is just so significant, am I missing something? (Perhaps I should add that in my scenario it doesn't make sense to store the information XGroupController needs to give to XController via the model).
If by "controller" you mean a MVC view/interface controller then yes it is wrong because it breaks encapsulation. The data model should be completely unconcerned with how it's data is displayed.
If your "controller" is just an entity with that name then you probably want to use a fetched relationship to get the two controllers to talk to each other. That prevents circular relationships in the object graph.