12 lines
1.5 KiB
Plaintext
12 lines
1.5 KiB
Plaintext
An instance of an ''Entity'' is distinct from all other domain objects, even if the contents of the Entity are exactly the same as another one. Contrast this to a ValueObject.
|
|
|
|
In storytests, we want to be able to refer to an existing ''Entity'', as well as to create a new one and to match the contents of an existing one.
|
|
|
|
This is awkward if the ''Entity'' class doesn't have a visible key (the actual key may be auto-generated by the database). So in storytests, we make sure that the ''Entities'' we're dealing with do differ in some way so that we can distinguish them. Thus we effectively introduce a temporary key for the purposes of a storytest. Then we are able to refer to an existing ''Entity'' by using a real or temporary key.
|
|
|
|
For a good introduction to the notion of ''Entity'', see DomainDrivenDesign.
|
|
!3 Programming
|
|
An ''Entity'' key is specified with a String. When an ''Entity'' is expected in a table cell and that cell contains a String, ${fitLibrary} treats the String as a key and calls a ${finder} method to lookup the corresponding Entity by the given key. So how do we know whether such a String is a key, rather than a direct representation of the ''Entity'', as is the case with a ValueObject?
|
|
|
|
${fitLibrary} follows the convention that an ''Entity'' will '''not''' have a ''public static Object parse(String)'' method (as compared to a ValueObject that often will). This does rule out an ''Entity'' that is a single value that can be represented in a String, unfortunately.
|