In a mileage-tracking app I am developing, the concepts include "Places," "Legs," and "Routes." Essentially, a Route is a collection of connected Legs, where each Leg is simply a straight line between two Places (with an associated distance).
I am having a problem modeling the Route-Leg relationship in Core Data because a Route may include the same Leg twice or more. For example, a person could travel Home to Office, Office to Worksite, Worksite to Home, Home to Office, and Office to Home as a single, contiguous path of travel on a given day. In that case, the "Home-to-Office" Leg is contained twice in the Route. But Core Data creates the To-Many relationship in a NSManagedObject subclass as an instance of NSOrderedSet, which does not permit duplicate Legs.
Is there a way I can create a relationship between the two Core Data-backed objects (Route and Leg) that allows multiple occurrences of the same Leg in a single Route? I am developing my app in Swift, so any Swift-specific suggestions would be appreciated.
Thank you.
Presumably you currently have a many-many relationship between Leg and Route. One solution is to replace this many-many relationship with an intermediate entity (say RouteLegDetails) which has to-one relationships with Leg and Route. Each Route can have many RouteLegDetails and likewise each Leg can have many RouteLegDetails. In the data model editor, it might look something like this:
This way, if you have a Leg that is traversed twice (or more) on the same Route, each instance is represented by a different RouteLegDetails: which overcomes the restriction on duplicates in the legDetails ordered set.
This will complicate your code slightly: when you want to add a Leg to a Route, you will have to create a RouteLegDetails object, and add it to both the legDetails relationship on the Route and the routeDetails relationship on the Leg. Conversely to remove a Leg from a Route, you will need to delete the corresponding RouteLegDetails object.
It seems like there might be an opportunity to improve your model object to solve this challenge. As I understand it now, you will not be able to fully define a route based on what you are currently modelling. How could you fully define a route from its constituent legs? Since the relationship is inherently unordered there is no way to build a route from the legs by just examining the relationship as you will not know in which order the legs occur.
One option is to store an order property with your leg object. A leg with the same start and end point, but a different order would be a distinct object.
A second and possibly cleaner approach would be to store the order of the legs in the route object (perhaps as a list of leg IDs leg 1 -> leg 3 -> leg 4 -> leg 1 -> leg 2). The legs relationship would get you all legs to build the route, the leg order property stored in the route object would allow you to construct the route from its legs, even if you use the same one twice. An array is the obvious way to store the order of the legs by ID, however an array is not a supported core data type, you may want to consider storing the order of the leg IDs as a string you can parse or a transformable attribute. See Transformable Attribute
Related
First, don't think i'm trying to get the job done by someone else, but i'm trying to design a class diagram for a domain model and something I do is probably wrong because I'm stuck, so I just want to get hints about what i'm not doing correctly to continue...
For example, the user needs to search products by categories from a product list. Each category may have subcategories which may have subcategories, etc.
The first diagram I made was this (simplified):
The user also needs to get a tree list of categories which have at least one product.
For example, if this is all the categories tree:
Music instruments
Wind
String
Guitars
Violins
Percussion
Books
Comics
Fiction
Romance
I can't return a tree of Category which have at least one product because I would also get all subCategories, but not each sub category has a product associated to it.
I also can't remove items from the Category.subCategories collection to keep only items which have associated products because it would alter the Category entity, which may be shared elsewhere, this is not what I want.
I thought of doing a copy, but than I would get 2 different instances of the same entity in the same context, isn't it a bad thing ?
So I redesigned to this:
Now I don't get a collection of child categories I don't want with each Category, I only know about its parent category, which is ok.
However, this creates a tree of categories which is navigable only from the bottom to the top, it makes no sense for the client of ProductList who will always need a top -> bottom navigation of categories.
As a solution I think of the diagram below, but i'm not sure it is very good because it kinda dupplicates things, also the CategoryTreeItem does not seems very meaningful in the domain language.
What am I doing wrong ?
This is rather an algorithmic question than a model question. Your first approach is totally ok, unless you were silent about constraints. So you can assign a category or a sub-category to any product. If you assign a sub-category, this means as per this model, the product will also have the parent category. To make it clear I would attach a constraint that tells that a product needs to be assigned to the most finest know category grain. E.g. the guitar products would be assigned to the Guitar category. As more strange instrument like the Stick would get the Strings category (which not would mean its a guitar and a violin but just in the higher category.
Now when you will implement Category you might think of a method to return a collection of assignedInstruments() which for Guitar would return Fender, Alhambra, etc. You might augment this assignedInstruments(levelUp:BOOL) to get also those instruments of the category above.
Generally you must be clear about what the category assignment basically means. If you change the assignment the product will end up in another list.
It depends on the purpose of the diagram. Do you apply a certain software development method that defines the purpose of this diagram in a certain context and the intended readers audience?
Because you talk about a 'domain model', I guess your goal is to provide a kind of conceptual model, i.e. a model of the concepts needed to communicate the application's functionality to end users, testers etc. In that case, the first and the second diagram are both valid, but without the operations (FilterByCategory and GetCategories), because these are not relevant for that audience. The fact that the GUI only displays a subset of the full category tree is usually not expressed in a UML diagram, but in plain text.
On the other hand, if your intention is to provide a technical design for developers, then the third diagram is valid. The developers probably need a class to persist categories in the database ('Category') and a separate class to supply categories to the GUI ('CategoryTreeItem'). You are right that this distinction is not meaningful in the domain language, but in a technical design, it is common to have such additional classes. Please check with the developers if your model is compatible with the programming language and libraries/frameworks they use.
One final remark:
In the first diagram, you specified multiplicity=1 on the parent side. This would mean that every Category has a parent, which is obviously not true. The second diagram has the correct multiplicity: 0..1. The third diagram has an incorrect multiplicity=1 on the composition of CategoryTreeItem.
From my perspective your design is overly complex.
Crafting a domain model around querying needs is usually the wrong approach. Domain models are most useful to express domain behaviors. In other words, to process commands and protect invariants within the correct boundaries.
If your Product Aggregate Root (AR) references a Category AR by id and this relationship is stored in a relationnal DB then you can easily fulfill any of the mentionned querying use cases with a simple DB query. You'd start by gathering a flat representation of the tree which could then be used to construct an in-memory tree.
These queries could be exposed through a ProductQueryService that is part of the application layer, not the domain as those aren't used to enforce domain rules or invariants: I assumed they are used to fullfil reporting or UI display needs. It is there you could have a concept such as ProductCategoryTreeItemDTO for the in-memory representation.
You are also using the wrong terms according to DDD tactical patterns in your diagrams which is very misleading. An AR is an Entity, but an Entity is not necessarily an AR. The Entity term is mostly used to refer to a concept that is uniquely identified within the boundary of it's AR only, but not globally.
I have a problem with my UML diagram and I'll be happy if you help me. I have relationships like
Object A (1)<>----(0..*) Object B
Object B (1)<>----(0..*) Object A
and I'd like to unite them. How can I do it? Thanks a lot.
Can you please define the term "unite them"? What exactly would you like to achive? An example could probably help.
Meanwhile, I can try to guess and give you two possible solutions. Maybe they help you to rephrase your question or even to find the solution:
In the Solution 1, I've just made a single relationship that describes both of yours. This can be used if there is only a single and clear criterion of the linkage between the objects. A typical n..m relationship. Objects A will each hold a collection of related objects B and vice versa.
For example a Person (A on the diagram) can join several Clubs (B) and a Club can have several members - there is only one logical relation behind this situation - membership.
Solution 2 is where there are actually 2 different ways to relate between those elements, each one 1..n. So, A holds a collection of Bs and B holds collection of As, but they are unrelated.
Extending the same example - a Person (A) can join only 1 Club (B) and a Club can have many members and hold their reference (col_a on the diagram). In the same time, a Club can have only 1 owner, and a Person can own several Clubs (col_b). Here we have two different logical relations - membership and ownership.
Of course, other multiplicities and navigabilities are possible, this is just an example to give you an idea.
Does one of these situations sound like yours?
UPDATE (after the 1st comment):
So, here is the updated solution 1:
This is an aggregation used here, and this is more a Group-member relationship. It suits perfectly the description of my first solution up there. Members (B) can be "shared" between the Groups (A) and Gruop does not have any special control over their lifetime.
The real Whole-part relationship would employ composition instead of aggregation (visually depicted with a black diamond, instead of a white one). Its semantics it that Whole object has a full control over the life of the contained objects (parts). In consequence, the Parts cannot be shared between several Wholes and must be destroyed if the Whole itself is destroyed.
Now you just need to find out which situation describes your problem the best, pick-up on of this solutions and eventually fine tune the multiplicities.
Here is a way you could represent this scenario in UML.
One server can contain 0 or many Functions (ie. aggregate relationship).
Each function must belong to one server. Or if it is a distributed function then it can belong to many servers.
Let's say you have a many to many relationship between two entities and you use MagicalRecord to manually tie them together.
IE: A Vet has many Pets and a Pet has many Pets
In the code, do you need to add the entity on both sides of the relationship;
ie:
[vet1 addPetObject:cust1Pet1];
[vet1 addPetObject:cust1Pet2];
[vet1 addPetObject:cust1Pet3];
[cust1Pet1 addVetObject:vet1];
[cust1Pet2 addVetObject:vet1];
So, do I need to add the pet object to the vet, and then add the vet to the relevant pet object -- or will Core data / Magical record handle this relationship and tie them on both sides by itself?
Many thanks.
If the relationships are defined as inverse relationships of each other in the Core Data
model inspector then you need only set one of them. Core Data will automatically update
the inverse relationship. (This is in fact unrelated to MagicalRecord.)
I´m a little confused about inheritance and relationships in core data, and I was hopping someone could drive to the right path. In my app i have created 3 entities, and none of them have (and are not suppose to have) common properties, but there´s gonna be a save and a load button for all the work that the user does. From my understanding I need to "wrap" all the entities "work" into an object which will be used to save and load, and my question is, do I need to create relationships between the entities? Because I have to relate them somehow and this is what make sense to me. Is my logic correct?
I'm implementing a budget calculator, and for the purpose of everyone understand what my issue is, I´m going to give an practical example and please correct me if my logic is incorrect:
Let´s just say you are a fruit seller, and because of that it´s normal to have a database of clients and also a fruit database with the kinds of fruit you sell. From my understanding I find two entities here:
Client with properties named: name, address, phone, email, etc.
Stock with properties named: name, weight, stock, cost, supplier, etc.
TheBudget with properties named: name, amount, type, cost, delivery, etc.
I didn´t put all the properties because I think you get the point. I mean as you can see, there´s only two properties I could inherit; the rest is different. So, if I was doing a budget for a client, I can have as many clients I want and also the amount of stock, but what about the actual budget?
I´m sorry if my explanation was not very clear, but if it was..what kind of relationships should I be creating? I think Client and TheBudget have a connection. What do you advise me?
That's not entirely correct, but some parts are on the right track. I've broken your question down into three parts: relationships, inheritance and the Managed Object Context to hopefully help you understand each part separately:
Relationships
Relationships are usually used to indicate that one entity can 'belong' to another (i.e. an employee can belong to a company). You can setup multiple one-to-many relationships (i.e. an employee belongs to a company and a boss) and you can setup the inverse relationships (which is better described with the word 'owns' or 'has', such as 'one company has many employees).
There are many even more complicated relationships depending on your needs and a whole set of delete rules that you can tell the system to follow when an entity in a relationship is deleted. When first starting out I found it easiest to stick with one-to-one and one-to-many relationships like I've described above.
Inheritance
Inheritance is best described as a sort of base template that is used for other, more specific entities. You are correct in stating that you could use inheritance as a sort of protocol to define some basic attributes that are common across a number of entities. A good example of this would be having a base class 'Employee' with attributes 'name', 'address' and 'start date'. You could then create other entities that inherit from this Employee entity, such as 'Marketing Rep', 'HR', 'Sales Rep', etc. which all have the common attributes 'name', 'address' and 'start date' without creating those attributes on each individual entity. Then, if you wanted to update your model and add, delete or modify a common attribute, you could do so on the parent entity and all of its children will inherit those changes automatically.
Managed Object Context (i.e. saving)
Now, onto the other part of your question/statement: wrapping all of your entities into an object which will be used to save and load. You do not need to create this object, core data uses the NSManagedObjectContext (MOC for short) specifically for this purpose. The MOC is tasked with keeping track of objects you create, delete and modify. In order to save your changes, you simply call the save: method on your MOC.
If you post your entities and what they do, I might be able to help make suggestions on ways to set it up in core data. You want to do your best to setup as robust a core data model as you can during the initial development process. The OS needs to be able to 'upgrade' the backing store to incorporate any changes you've made between your core data model revisions. If you do a poor job of setting up your core data model initially and release your code that way, it can be very difficult to try and make a complicated model update when the app is in the wild (as you've probably guessed, this is advice born out of painful experience :)
Quotes are from DDD: Tackling Complexity in the Heart of Software ( pg. 150 )
a)
global search access to a VALUE is often meaningles, because finding a
VALUE by its properties would be equivalent to creating a new instance
with those properties. There are exceptions. For example, when I am
planning travel online, I sometimes save a few prospective itineraries
and return later to select one to book. Those itineraries are VALUES
(if there were two made up of the same flights, I would not care which
was which), but they have been associated with my user name and
retrieved for me intact.
I don't understand author's reasoning as for why it would be more appropriate to make Itinierary Value Object globally accessible instead of clients having to globally search for Customer root entity and then traverse from it to this Itinierary object?
b)
A subset of persistent objects must be globaly accessible through a
search based on object attributes ... They are usualy ENTITIES,
sometimes VALUE OBJECTS with complex internal structure ...
Why is it more common for Values Objects with complex internal structure to be globally accesible rather than simpler Value Objects?
c) Anyways, are there some general guidelines on how to determine whether a particular Value Object should be made globally accessible?
UPDATE:
a)
There is no domain reason to make an itinerary traverse-able through
the customer entity. Why load the customer entity if it isn't needed
for any behavior? Queries are usually best handled without
complicating the behavioral domain.
I'm probably wrong about this, but isn't it common that when user ( Ie Customer root entity ) logs in, domain model retrieves user's Customer Aggregate?
And if users have an option to book flights, then it would also be common for them to check from time to time the Itineraries ( though English isn't my first language so the term Itinerary may actually mean something a bit different than I think it means ) they have selected or booked.
And since Customer Aggregate is already retrieved from the DB, why issue another global search for Itinerary ( which will probably search for it in DB ) when it was already retrieved together with Customer Aggregate?
c)
The rule is quite simple IMO - if there is a need for it. It doesn't
depend on the structure of the VO itself but on whether an instance of
a particular VO is needed for a use case.
But this VO instance has to be related to some entity ( ie Itinerary is related to particular Customer ), else as the author pointed out, instead of searching for VO by its properties, we could simply create a new VO instance with those properties?
SECOND UPDATE:
a) From your link:
Another method for expressing relationships is with a repository.
When relationship is expressed via repository, do you implement a SalesOrder.LineItems property ( which I doubt, since you advise against entities calling repositories directly ), which in turns calls a repository, or do you implement something like SalesOrder.MyLineItems(IOrderRepository repo)? If the latter, then I assume there is no need for SalesOrder.LineItems property?
b)
The important thing to remember is that aggregates aren't meant to be
used for displaying data.
True that domain model doesn't care what upper layers will do with the data, but if not using DTO's between Application and UI layers, then I'd assume UI will extract the data to display from an aggregate ( assuming we sent to UI whole aggregate and not just some entity residing within it )?
Thank you
a) There is no domain reason to make an itinerary traverse-able through the customer entity. Why load the customer entity if it isn't needed for any behavior? Queries are usually best handled without complicating the behavioral domain.
b) I assume that his reasoning is that complex value objects are those that you want to query since you can't easily recreate them. This issue and all query related issues can be addressed with the read-model pattern.
c) The rule is quite simple IMO - if there is a need for it. It doesn't depend on the structure of the VO itself but on whether an instance of a particular VO is needed for a use case.
UPDATE
a) It is unlikely that a customer aggregate would have references to the customer's itineraries. The reason is that I don't see how an itinerary would be related to behaviors that would exist in the customer aggregate. It is also unnecessary to load the customer aggregate at all if all that is needed is some data to display. However, if you do load the aggregate and it does contain reference data that you need you may as well display it. The important thing to remember is that aggregates aren't meant to be used for displaying data.
c) The relationship between customer and itinerary could be expressed by a shared ID - each itinerary would have a customerId. This would allow lookup as required. However, just because these two things are related it does not mean that you need to traverse customer to get to the related entities or value objects for viewing purposes. More generally, associations can be implemented either as direct references or via repository search. There are trade-offs either way.
UPDATE 2
a) If implemented with a repository, there is no LineItems property - no direct references. Instead, to obtain a list of line items a repository is called.
b) Or you can create a DTO-like object, a read-model, which would be returned directly from the repository. The repository can in turn execute a simple SQL query to get all required data. This allows you to get to data that isn't part of the aggregate but is related. If an aggregate does have all the data needed for a view, then use that aggregate. But as soon as you have a need for more data that doesn't concern the aggregate, switch to a read-model.