I am trying to get started with using Azure tables. I learnt that Azure tables store objects of a particular class. Could you please tell me how the table accomodates versioining of classes?
Suppose there is a class A with property p1 to start with and say we have stored objects o1 and o2 of type A into a table T. Lets say later we add another property p2 to A. Now, what kind of behavior would we get when we use the new definition of A to retrieve o1 and o2? Will it throw some error? If not, what would be the value of p2 for thee objects when retrieved?
Or is the developer responsible for managing different class definitions in his application?
Very important note: Don't think of Azure Tables as an object store! Think of it as a key-value store with non-fixed schema.
Going for you particular example. When you store o1 and o2 from class A, you will have 2 rows in your table:
PartitionKey_1, RowKey_1, p1_1
PartitionKey_2, RowKey_2, p1_2
Then you add new property to that class and store the object. The result will be a third row:
PartitionKey_3, RowKey_3, p_3, p2_1
Later you can retrieve all the data you need and map it to an instance of a class that has property names corresponding to the table columns!
If you try to fetch the first two records into the latest class A, you will simply get a NULL (or default value for value types) for the p2 property.
If you try to fetch row 3 into earlier class A, you will only get the p1 property value. (Eventually you may see an error, but not a crucial one, you will still be able to map P1 column from the table to the P1 property of your object).
As a reference Understanding Table Service data model is very good starting point for you.
As you just begin, I also suggest that you go through the Windows Azure Storage Client library 2.0 - Tables Deep Dive. This article describes in very details how to save and fetch data from Azure tables.
Precisely, when you retrieve the first three objects, they will simply come out without p2. If you are using the default deserialization methods of class TableEntity, your objects will have p2 as null.
Related
I was trying to understand DDD value objects and entities, and have a minor doubt in that. I've read in a lot of articles that value objects does not have identity. I wanted clarity on whether that the identity referred here is a single attribute or a any composite attributes.
Lets say I have an inventory management service which has a business transaction called "Inventory Adjustment", what it does is simply adjusts the quantity of items at your warehouse. You can create an adjustment with multiple line items, each line item will have an ItemID and Quantity fields.
Note: Lets assume that an item can occur only once in an adjustment, meaning an adjustment cannot have multiple line items with same Item ID.
The user can edit an adjustment line item, delete line items and add new line items as well.
In this context, is adjustmentLineItem a value object OR an entity inside adjustment root aggregate?
The confusion I have is when we say VOs should not have an identity, does that mean it should not have an ID field or a composite identity as well. Because in my case, I would not need an ID field for the line item object, the AdjustmentID + ItemID serves as an identifier for me.
Also, is it fine to have the parent entity identifier inside a VO (like adjustmentID)?
Not related to this context, in general what is the reason why VOs should not have identities?
NOTE: I am relatively new to DDD and my understandings might be wrong.
There's a difference between identifier and identity.
An identifier is a value that identify something, is what an entity use to track its identity.
The identity instead is what tells you that an entity is different from another one, you can use a number to do it (like in case of sql db sequences) or some UUID, or basically use a value that acts as an identifier
Difference between value objects and entities reside in the identity of the latter.
If we have an entity, let's say a Person, and we do a change (mutate) to it (eg. change name), it still remain the same entity (a person changing name still remain the same person). That is not true for value objects, if we have an Address and we change its street it is a different Address.
When we reify this abstraction into code, we need something to track the identity of an entity, to be able to check and confront it with another one. In these cases we add a value in the entity that acts as an identifier, something that we know will stay the same for the entire lifecycle of the entity.
So the identifier can be seen as a value and it can be treat as such.
Then going back to the questions:
It seems to me that in your case the InventoryAdjustment is the entity (it has its own identity), and it contains the list of AdjustmentLineItem that could be seen as a value, containing the ItemId that is also a value.
AdjustmentLineItem is a VO itself
Code to work with things not having an identity is simpler as they can easily be immutable, avoiding a lot of issues (you can look for the immutability topic to understand them, or there's this famous talk about Values)
A final note about this rule:
Lets assume that an item can occur only once in an adjustment
This enforce the fact that the InventoryAdjustment is an entity, and this rule is one of its invariants.
The InventoryAdjustment has a value in it being a List<AdjustmentLineItem>, and could check the rule when someone try to mutate it. When doing domain models, the access for editing purposes to the state of the entity should be disallowed, no setter methods and make impossible for external code of the InventoryAdjustment to do things like:
inventoryAdjustment.getAdjustmentLineItemList().add(anAdjustmentLineItem)
but rather expose methods to do mutation, and internally check invariants:
inventoryAdjustment.addAdjustmentLineItem(anAdjustmentLineItem)
I'm building a workout app that has an entity called Workout and another one called Exercise.
A workout can contain multiple exercises (thus a one-to-many relationship). I want to show the users of my app the exercises contained in a workout but in an ordered way (it's not the same to start with strength exercises as with the cardio ones).
Apparently, when establishing this kind of relationship in Core Data, I need to use an NSSet, because if I try to use for example an Array where its elements are ordered, I get the following error:
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Unacceptable type of value for to-many relationship: property = "consistsOf"; desired type = NSSet; given type = __NSArray0; value = (
).'
I have tried to check the "ordered" checkmark in my model, but then I get an error saying "Workout.consistsOf must not be ordered".
I have also tried to use an NSDictionary whose keys would be the position and the values would be the exercises themselves, but I'm getting the same error as above.
How can I show the users the exercises that a workout consists of in an ordered way?
Thanks a lot in advance!
P.S.: Here's a screenshot of the properties of my model.
Ordered relationships use NSOrderedSet, but CloudKit doesn't support ordered sets, so you can't use an ordered relationship and CloudKit in the same data model.
To keep an order, you need to have some property on Exercise that would indicate the order. This could be as simple as an integer property called something like index. You'd sort the result based on the index value. If there's something else that also indicates order-- like a date, maybe?-- use that instead of adding a new property.
I have a composite relationship between two objects (A & B) (A is composed of many Bs). Now another class (C) has a one-to-many association relationship to class 'B'. I would like to be able to retrieve all instances of class (A) from class (C).
How do I do this without creating redundant associations? Since 'C' has basically a list of 'Bs' I can't just iterate over all of them asking what's your 'A' and eventually returning a list of 'A' to 'C'.
I really hope someone out there understands this and doesn't find it completely confusing!
Thanks
Update:
Dataset has a list of defined variables. An activity can select a subset of variables from each dataset and give some attributes to them, hence an association class is used. Now if I want to be able to retrieve from an Activity instance the datasets it is registered with, how do I achieve this in UML and in object implementation?
According to your task, it is IMPOSSIBLE to take all B's from all C's. Because there is no sentence that states that any B belong to some C.
On the contrary, as A have compositions of B (notice, A IS NOT composition, A HAS composition of B, for A can have heaps of other things, too), and any B MUST belong to some A object, you can easily get all B's from all A's. Only create the list of B as a set for not to have multiply values.
But even if the association B-A includes B->A connection, you cannot get all A's from B's. Because some A's can be EMPTY. You'll never reach them. from B's.
So, you cannot take all A from C's for TWO important reasons. And NO redundant association will help.
As for the question set after "Update",
For getting All from variables, use
Dataset <---- Variable ---> Activity // This variant is the easiest for adding associations.
For getting connected datasets from an activity,
Dataset <--- Variable <----- Activity
But please, notice, it is not updated, it is DIFFERENT question.
I assume your diagram would look something like this :
If C has a reference to B, and B has a reference to A, then it should be no problem navigating to A from C. There is no need for any additional redundant relationships.
I have a SQLCe database which had a unique primary key Id with type uniqueidentifier, and child relationship, 1 to many, where i keep the master id in a column and append unique id for every row too. Now I use POCO entities for my domain model NOT STE. While adding and modifying entities works OK, I have hard time to delete, say for now individual child records, where of course supposed that they have they're own primary key. Soon as i give the deleted list and iterate through each entity while first entity is attached, in the second i get the exception:
An object with the same key already exists in the ObjectStateManager. The ObjectStateManager cannot track multiple objects with the same key.
I should mention that i first make any add and modify entities to the database while opening a context...disposing and call another method for deletion where of course opens another context and if it ends successfully disposing.
Whats the meaning for this exception that I don't get?
This exception occurs when you have two different instances of the same entity in your object graph. This exception also occurs in STE but there is a work-around for that.
Basically, you have two entities (POCO), each with a relationship to a third entity. When you try to associate the first entity with the second and try to persist it into the Entity Context, both entities will have a seperate instance of the third and this is where the error is.
Work-around:
Before you make the association between two entities, try to "merge" any related entities together. This is so that the Entity Context does not need to make the decision of which instance of the "common entity" to persist.
Example:
A, (B1,B2), C are entities.
A -- B1
C -- B2
A -- B1 -- C
In this scenario, B1 and B2 are both B entities, just different instances (may be due to different calls to the data store through different contexts). When you want to associate A and C, you must choose to drop B2 and link C to B1.
I have just started reading DDD. I am unable to completely grasp the concept of Entity vs Value objects.. Can someone please explain the problems (maintainability, performance.. etc) a system could face when a Value object is designed as a Entity object? Example would be great...
Reduced to the essential distinction, identity matters for entities, but does not matter for value objects. For example, someone's Name is a value object. A Customer entity might be composed of a customer Name (value object), List<Order> OrderHistory (List of entities), and perhaps a default Address (typically a value object). The Customer Entity would have an ID, and each order would have an ID, but a Name should not; generally, within the object model anyway, the identity of an Address probably does not matter.
Value objects can typically be represented as immutable objects; changing one property of a value object essentially destroys the old object and creates a new one, because you're not as concerned with identity as with content. Properly, the Equals instance method on Name would return "true" as long as the object's properties are identical to the properties of another instance.
However, changing some attribute of an entity like Customer doesn't destroy the customer; a Customer entity is typically mutable. The identity remains the same (at least once the object has been persisted).
You probably create value objects without realizing it; anytime you are representing some aspect of an Entity by creating a fine-grained class, you've got a value object. For example, a class IPAddress, which has some constraints on valid values but is composed of simpler datatypes, would be a value object. An EmailAddress could be a string, or it could be a value object with its own set of behaviors.
It's quite possible that even items that have an identity in your database don't have an identity in your object model. But the simplest case is a composite of some attributes that make sense together. You probably don't want to have Customer.FirstName, Customer.LastName, Customer.MiddleInitial and Customer.Title when you can compose those together as Customer.Name; they'll probably be multiple fields in your database by the time you think about persistence, but your object model doesn't care.
Any object that is collectively defined by all of it attributes is a value object. If any of the attributes change you have a new instance of a value object. This is why value objects are defined as immutable.
If the object is not fully defined by all of its attributes then there are a subset of attributes that make up the identity of the object. The remaining attributes can change without redefining the object. This kind of object cannot be defined at immutable.
A simpler way of making the distinction is to think of value objects as static data that will never change and entities as data that evolves in your application.
Value Types :
Value types do not exist on his own, depends on Entity types.
Value Type object belongs to an Entity Type Object.
The lifespan of a value type instance is bounded by the lifespan of the owning entity instance.
Three Value types: Basic(primitive datatypes), Composite(Address) and Collection(Map, List, Arrays)
Entities:
Entity types can exist on his own (Identity)
An entity has its own life-cycle. It may exist independently of any other entity.
For example: Person, Organisation, College, Mobile, Home etc.. every object has its own identity
I don't know if the following is correct, but I would say that in the case of an Address object, we want to use it as a Value Object instead of an Entity because changes to the entity would be reflected on all linked objects (a Person for instance).
Take this case: You are living in your house with some other people. If we would use Entity for Address, I would argue that there would be one unique Address that all Person objects link to. If one person moves out, you want to update his address. If you would update the properties of the Address Entity, all people would have a different address. In the case of a Value Object, we would not be able to edit the Address (since it is immutable) and we would be forced to provide a new Address for that Person.
Does this sound right? I must say that I was/am also still confused about this difference, after reading the DDD book.
Going one step further, how would this be modelled in the database? Would you have all properties of the Address object as columns in the Person table or would you create a separate Address table that would also have a unique identifier? In the latter case, the people living in the same house would each have a different instance of an Address object, but those objects would be the same except for their ID property.
address can be entity or value object that depends on the busiess process. address object can be entity in courier service application but address can be value object in some other application. in courier application identity matters for address object
3 distinction between Entities and Value Objects
Identifier vs structural equality:
Entities have identifier,entities are the same if they have the same
identifier.
Value Objects on beyond the hand have structural equality, we consider two
value objects equal when all the fields are the same. Value objects cannot
have identifier.
Mutability vs immutability:
Value Objects are immutable data structures whereas entities change during
their life time.
Lifespan: Value Objects Should belong to Entities
In a very simple sentence I can say, we have three types of equality:
Identifier equality: a class has id filed and two objects are compared with their id field value.
Reference equality: if a reference to two objects has a same address in memory.
Structural equality: two objects are equal if all members of them are matched.
Identifier equality refers only to Entity and structural equality refers to Value Object only. In fact Value Objects do not have id and we can use them interchangeably. also value objects must be immutable and entities can be mutable and value objects will not have nay table in database.
I asked about this in another thread and I think I'm still confused. I may be confusing performance considerations with data modelling. In our Cataloging application, a Customer doesn't change until it needs to. That sounds dumb - but the 'reads' of customer data far outnumber the 'writes' and since many many web requests are all hitting on the 'active set' of objects, I don't want to keep loading Customers time and again. So I was headed down an immutable road for the Customer object - load it, cache it, and serve up the same one to the 99% of (multi-threaded) requests that want to see the Customer. Then, when a customer changes something, get an 'editor' to make a new Customer and invalidate the old one.
My concern is if many threads see the same customer object and it is mutable, then when one thread starts to change it mayhem ensues in the others.
My problems now are, 1) is this reasonable, and 2) how best to do this without duplicating a lot of code about the properties.
Consider the following examples from Wikipedia, in order to better understand the difference between Value Objects and Entities:
Value Object: When people exchange dollar bills, they generally do not
distinguish between each unique bill; they only are concerned about the face
value of the dollar bill. In this context, dollar bills are Value Objects. However,
the Federal Reserve may be concerned about each unique bill; in this context each
bill would be an entity.
Entity: Most airlines distinguish each seat uniquely on every flight. Each seat is
an entity in this context. However, Southwest Airlines, EasyJet and Ryanair do
not distinguish between every seat; all seats are the same. In this context, a seat is
actually a Value Object.