This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi Guys, I would like to know how well lightspeed supports the DDD idea of a Aggregate Root where by it add or remove child collections and references when the root is saved or deleted..?
Simple example: Store and Employees. You have a store and then add/remove employees from the store. Does lightspeed have the abiliy to track which employees have been removed so that when you save the store these events cascade down employees collection? This is something that I know NHibernate supports and feels a bit more natural and closer to DDD. Here is the NHibernate example I was looking at http://wiki.fluentnhibernate.org/show/GettingStarted:+First+Project
P.s The Lightspeed + asp.net mvc community code initiative sounds interesting!
Cheers
Jake Scott
|
|
|
Yes, this is what LightSpeed does. For example: using (var uow = context.CreateUnitOfWork()) Alice will be added to the database (with an appropriate StoreId foreign key), and Bob will be deleted from the database. You do not need to explicitly add Alice to the UOW or remove Bob from the UOW. Note that automatic delete does not happen if the collection is not dependent -- if the domain model supports Employees who are not associated with a Store then Bob will *not* be deleted automatically, he will just have his StoreId foreign key set to NULL. |
|
|
Thanks Ivan sounds good. So the automatic delete would not happen in the case of a many to many relationship such as Store - StoreProduct - Product as the Product has its own life cycle independant of the Store? Cool well I will do my best to persuade my work to get off linq to sql. I did do one project using nHibernate and Fluent nHibernate but I think it would be a mission teaching all the other devs how to use it. Also nHibernate sql formatting is v hard to read. |
|
|
Yes, I believe what you describe for the many-to-many case is correct: deleting a Store would delete all associated StoreProducts, but the deletion of those StoreProducts would *not* cause deletion of their parent Products. (I.e. deleting a parent deletes all children, assuming that the relationship is dependent (non-nullable), but deleting children does not delete the parent.) |
|
|
Ivan, quick question: Is there a way (via an attribute or even something like a CASCADE DELETE restriction on the database schema) to indicate when we are dealing with a "dependent collection"? We are familiar with the "not deleted, instead the parentID field is unset" behavior already, but I'm double-checking to make sure we didn't miss something obvious. Thanks! |
|
|
Collections are automatically dependent if the foreign key is non-nullable. (In the designer this is controlled by the Is Nullable setting on the one-to-many association arrow. In code it is controlled by whether the foreign key field, e.g. parentId, is of a nullable type e.g. int?/Nullable<int>.) If you want to cascade deletes when a parent is deleted, but you need the foreign key to be nullable, then set the Is Dependent setting on the association arrow to True (or, in code, apply DependentAttribute to the EntityCollection field). |
|
|
THANK YOU! |
|