Hey all,
I'm trying to sort the best way to leverage the framework for a particular kind of class that is cased on relationship that is sort of like ResourceAssignment in the projectTracker example.
In our case we have a Resource class with a child collection of Tags.
From a data perspective we find these tags via an association table because the relationship of Resources to Tags is many to many.
Initially I just defined a RelationshipTag child object and wrote stored procs that would query both the association table and the tag table, and handle saving to both the association table and the tag table as well.
But, I'm finding that I don't want to have to make changes to both the ResourceTag AND the tag classes when the business rules change, so... it makes sense that ResourceTag needs to use Tag when necessary and I have to give in to the natural "behaves like" that is staring me in the face.
So, the ResourceTag behaves like a Tag, but has the additional ID field that ties it to the resource to which it belongs. The properties of the ResourceTag are essentially all the fields of the Tag + the ResourceID it's tied to.
finally my question...
I'm looking for ease and best practice here. I don't REALLY want to define this via inheritance, but rather composition, it seems like that is predominant advice on this forum. So I create a ResourceTag object and within the class add a private Tag object to manage all the CRUD to the Tag (thereby getting to use all its methods).
If I define the Tag as a private child class within ResourceTag I can use the framework to do all the heavy lifting for me. I can then just map all the properties of the private child class up to the public properties of the parent class (ResourceTag). Is that the proper way to use the framework?
I just don't see any examples of when I look around on this forum of a parent class that hides a child class and just wraps the properties of that class.
Thanks for any and all advice...
Well in your case it sounds like the only behaivoral difference between ResourceTag and Tag is how the Tag data is retrieved, either one at a time to edit a tag, or all the Tags for a resource when the Resource is loaded.
If this is truly the case then you could just use the Tag class but you could run into performance issues since you would do a sql query to find the TagID associated with the Resource and loop through the results doing a Fetch on each ID to get a Tag to place in the Resource.Tags list.
To make it perform better you may have to perhaps add an alternate Fetch to Tag that takes a ResourceID and returns the List using SQL to gather all Tag data in one shot. Although others may chime and and suggest you not add that to Tag but instead make a ResourceTag that supports this new fetch being a different behaivor.
Justin
If Tag's behavior is what you want, inheritance may be an option for you, provided that the behaviors ResourceTag gets from Tag are always going to be the one that ResourceTag should keep.rfphill:
So, the ResourceTag behaves like a Tag, but has the additional ID field that ties it to the resource to which it belongs. The properties of the ResourceTag are essentially all the fields of the Tag + the ResourceID it's tied to.I'm looking for ease and best practice here. I don't REALLY want to define this via inheritance, but rather composition, it seems like that is predominant advice on this forum. So I create a ResourceTag object and within the class add a private Tag object to manage all the CRUD to the Tag (thereby getting to use all its methods).
Thanks to those who gave their opinions... I went the route of just making the actual tag class a private child class of the ResourceTag. I will just delegate to the Tag object all the CRUD chores of the tag based properties...
I guess my prevailing question is: When using composition/aggregation, like in this case, a Tag within a ResourceTag, should the Tag be a Editable Child?
If a ResourceTag 'has a' Tag, but the Tag is hidden/private, is the Tag considered an editable child?
I'm insanely out of my element here, but learning... thanks for your patience with these newbie questions..
I've been comparing your approach to the approach Rocky took in defining the Project, ProjectResources, ProjectResource hierarchy. I think it would help if you could contrast your situation with his.
I can see that Rocky ultimately resists the temptation to use composition in his case. Instead he passes a Resource (in your case I think this would be Tag) to the ProjectResource and then sets some private members. It seems he doesn't need to access the CRUD members of Resource from ProjectResource (In the context of ProjectTracker this makes a lot of sense)
Based on the approach you've described I have some questions:
i. Do you have a screen that allows you to edit Tag information outside of the context of any Resource? If so aren't you forced to create a ResourceTag object in order to update the Tag?
ii. How does your situation differ from Rocky's (re Project, ProjectResources and ProjectResource)?
I'm looking to adopt CSLA so I'm looking for all the feedback I can from real life problems and questions so thanks for posting!
rfphill:
Thanks to those who gave their opinions... I went the route of just making the actual tag class a private child class of the ResourceTag. I will just delegate to the Tag object all the CRUD chores of the tag based properties...
I guess my prevailing question is: When using composition/aggregation, like in this case, a Tag within a ResourceTag, should the Tag be a Editable Child?
If a ResourceTag 'has a' Tag, but the Tag is hidden/private, is the Tag considered an editable child?
I'm insanely out of my element here, but learning... thanks for your patience with these newbie questions..
Copyright (c) Marimer LLC