Object parenting itself #1751
-
Hi all, I'm having an issue where I can't to structure my object properly, the Parent property to be more precise. I have my AssetRE class `[Serializable]
}` OperationsListRE class `[Serializable]
And OperationRE `[Serializable]
My dataflow/workflow is a bit different from what I see here in the forum. I first get data from an external source, create the rule engine objects, run the rules and then save it on the database. When I create the Asset I create an empty OperationsList where I'm gonna add operations later. But when I add an operation to a OperationsList the Parent on the operations is itself not the operationsList. After creating the object the parent is null, which is correct. But after adding it to the list As you can see in the image the operationRE as it self as Parent. The more operations I add more Parents I have. Shouldn't the OperationList be the parent of the Operation? What am I doing wrong here? I'm fairly new to CSLA so I can be doing something basic thing wrong. Thanks in advance |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 11 replies
-
It's showing the correct relationship. The parent of a child business object is the list (OperationsListRE). You cannot skip from the child object directly to the the AssetRE object that is two levels up the object hierarchy. |
Beta Was this translation helpful? Give feedback.
-
Is the instance parenting itself? Or the type parenting another instance of the same type? |
Beta Was this translation helpful? Give feedback.
-
It starts with Asset [Serializable]
public class AssetRE : BusinessBase [AssetRE] (the edit didnt like the <>here)
{
public static readonly PropertyInfo<Guid> IdProperty = RegisterProperty<Guid>(c => c.Id);
public Guid Id
{
get => GetProperty(IdProperty);
set => SetProperty(IdProperty, value);
}
//omitting properties
public static readonly PropertyInfo<OperationsListRE> OperationsProperty = RegisterProperty<OperationsListRE>(nameof(Operations));
public OperationsListRE Operations
{
get => GetProperty(OperationsProperty);
set => LoadProperty(OperationsProperty, value);
}`
Then OperationsListRE which is a property of AssetRE
```c#
[Serializable]
public class OperationsListRE : BusinessBindingListBase<OperationsListRE, OperationRE>
{} Then OperationRE [Serializable]
public class OperationRE : BusinessBase[OperationRE] (the edit didnt like the <>here)
{
public static readonly PropertyInfo<Guid> IdProperty = RegisterProperty<Guid>(c => c.Id);
public Guid Id
{
get => GetProperty(IdProperty);
set => SetProperty(IdProperty, value);
}
//omitting properties
} So, it's: -AssetRE Asset has list of operations. I can see the Parent of OperationsListRE being AssetRE as it should but when I check the Parent property of any of the OperationRE it I see the object itself + it's "brothers". Like on this image I thought that the OperationRE parent would be the OperationsListRE, shouldn't it be? |
Beta Was this translation helpful? Give feedback.
-
It all looks correct to me. I think some of the Parent references in the watch window are being interpreted incorrectly. this is the list. Any graph with the child referencing the parent can be expanded in a circular fashion. If you override ToString on OperationRE and return the identity value for the operation, you will see that you are just showing a circular reference within the Watch window. Another test: |
Beta Was this translation helpful? Give feedback.
-
I ran the code and here are the results from some of the parent references that I added to the watch window.
I noted that the "raw" Parent result is an interface, which you can see in the first row. The second row is the same as the first, but cast back to the business class. The third row is a reference to operation.SubOperations[0].Parent[2].Parent. You cannot actually use that in the debugger because each Parent reference needs to cast back to the base class to access the children, but I'm effectively going to child 0, back to the parent, down to child 2, and back to the parent. The final row proves that they are indeed the same instance in memory. The debugger has trouble working with these kinds of circular references. For instance, I can right-click and "Add watch" on the top Parent, and the type returned is IParent. I can also add watch for the Parent of the sub operation, but the debugger generates its own generic debug view collection from the contents and things start to get confused. I don't thinks this is a fault of Csla. I think this is a debugger visualization limitation. |
Beta Was this translation helpful? Give feedback.
I ran the code and here are the results from some of the parent references that I added to the watch window.
I noted that the "raw" Parent result is an interface, which you can see in the first row.
The second row is …