Design question...
I have an "Editable Child" object (AddressBookEntry) in one of my projects that I've realized I should re-use in several other existing projects/assemblies. The problem is that "Editable Child" objects have their factory methods marked as "Friend", which makes it so objects in other projects/assemblies can't get at them.
I considered the following solutions...
- Converting it to an "Editable Root" object.....but decided against it because on the UI screens it is always edited as part of the parent entity (think transaction implications).
- Changing the editable child's factory method from Friend to Public.....but this seems dangerous because it opens them up to misuse or abuse.
- Making a copy of the editable child and put one in every project that wants to use it.....but this seems like it would create a lot of unnecessary maintenance.
How would you guys handle this situation?
Jason
Or...
If my question is unclear or I've misunderstood some key CSLA concept, please let me know.
Jason
I would not change CSLA or the way the BO is supposed to work.
I would copy it into the new project so if changes are required you don't have to be concerned with affecting other projects.
Joe
One other possible solution might be to create classes in other asemblies that inherit (without adding any additional functionality) from your EditableChild. Inherited classes could then still have internal (friend) factory methods and you avoid code duplication. You would just have to promote few private thing in your base class to protected...
Using the inherited classes is a very interesting idea. I'm going to play around with that today.
If anyone has been down that road already and run into any problems, please post. I'm specifically wondering if there will be any effect on PropertyChanged events and things serializing correctly.
Thanks,
Jason
I've been playing with the inheritance approach. I have a base Address object in one project and an inherited Address object in a different project. The factory method ("Get") of the inherited Address basically calls the factory method of the base Address. When I run the code and it gets to the factory method, I am getting an error that it cannot convert from one type of object to another (from the base Address to the inherited Address). I tried wrapping it in "CType" and "DirectCast" but that didn't help. I assumed it would be able to convert back and forth from base class to inherited class, but it can't. Does anybody have any idea what is happening and how I can fix this?
Jason
I have been down that road and you can't get there from where you are.
I am 99% sure you can't call the Base factory methods.
You should probably build new ones in your derived class which return the newly derived type.
The factory methods will call DataPortal_XYZ and then your derived class will use the implementation in your Base class to do the actual work.
Joe
Ok, so if I'm understanding you guys correctly....
The subclasses should have their own factory methods, constructors, and data access methods. And the subclasses' data access methods should call the data access methods of the base class.
That sound right?
I'll play around with it more today. Thanks - I really appreciate the help.
Jason
Yep.....that did it. It is working now. Thanks!
The only thing that concerns me is that I had to use the "Shadows" keyword on a couple of the methods inside the subclasses - methods like "Insert" and "Update" that were duplicated inside both the base class and subclasses. The documentation I read on the "Shadows" keyword was somewhat confusing and left me wondering if that was an ok thing to do.
Is using "Shadows" keyword in this situation a problem or bad practice?
(maybe one of you guys can explain "Shadows" more clearly than Microsoft does)
Thanks,
Jason
Copyright (c) Marimer LLC