-
-
Notifications
You must be signed in to change notification settings - Fork 406
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider supporting the ObjectFactory attribute on child types #2072
Comments
I'll be honest, I didn't think child objects could or would save through factory types, and I'm surprised that this ever worked. The concept behind factories is that the factory manages the root and all child types. If this worked in 4.5 it is purely by accident 😄 I notice that your factory code doesn't do anything to manage metastate (marknew, markold, etc.), which is fine for a test, but is a problem in production of course. I'll need to trace through the Also I see that you are trigger the child save operation in |
Thanks Rockford for your response. To clarify with CSLA 4.5.x. The FieldManager.UpdateChildren () method of CSLA 4.5 executed Child_XYZ even if the child entity had the Csla.Server.ObjectFactory [...] attribute. CSLA 5.4 throws an exception when the child entity is linked to a factory (I have many entities that are used as both root and child entity). (In my opinion, if the child entity has the attribute of using a factory, why not use it?) Thank you |
It is not a bad idea @yvansigouin - it is just outside the original design parameters of the factory model for the data portal. I wouldn't have it work using I looked at the code, and it is not a trivial thing to enable the use of a factory for a child object the correct way, because it was never part of the original design. It is something I might consider for CSLA 6, because part of the roadmap already includes some fairly big updates to the factory model. |
So @yvansigouin let's discuss how to get you moving forward. Having child factory types is not the problem. The problem is that the data portal only automatically invokes a factory for the root type, not for child types. The philosophy being that the data portal hands the responsibility of persisting the entire object graph (and of managing all metastate) off to you. Someone might implement this by having all root and child persistence behaviors in a single factory class. For a complex object graph, this would result in a lot of code in a single class. I think it is better to do something more like what you've done, where you have multiple factory types corresponding to the different domain types. However, the factories need to call each other: you can't rely on the data portal to invoke the child factories. That needs to be done by the parent factory. So I think you should be able to use your existing factory types, it is just that you need to change it so your child factory types are called from the parent factory, not from |
As part of improving the data portal factory model in CSLA 6, it might make sense to allow the
ObjectFactory
attribute on child types. This would probably mean adding behaviors to theObjectFactory
base type so it can help create/fetch/update child objects, much like theUpdateChildren
method inBusinessBase
.The train of thought is that a parent factory could call a base method asking to update children, and the data portal would use the child type's
ObjectFactory
attribute to find and invoke the child factory.Original post:
Describe the bug
Hi,
I am currently migrating a solution that includes several classes from CSLA 4.5.501 (which worked fine) to version 5.4.0 and I having issues with child entities. All my business entities use factories. The problem occurs during the Save() operation. It seems that CSLA can't find the factory method of the child entities and throw an exception.
Version and Platform
CSLA version: 5.4.0 (and 5.4.1 preview)
OS: Windows 10
Platform: .NET 5 And Visual Studio 2019.
Code that Fails
Here a test exemple to add in csla.netcore.test project:
Stack Trace or Exception Detail
Additional context
The text was updated successfully, but these errors were encountered: