in a recent project, i have a scenario set up like this:

• Namespace Business_Objects:
• BaseBOs
• CustomersBO
• ContractsBO
• ContactsBO
• ClientsBO..
• Customer Maintanance
• CustomersBO (subclasssed from BaseBOs CustomersBO)
• ClientsBO (subclassed from BaseBOs ClientsBO)
• ..
• Contracts Maintanance
• CustomersBO (subclassed from BaseBOs CustomersBO)
• ContractsBO (subclassed from BaseBOs ContractsBo)
• ..
• .. and so on

i was wondering if anyone got some naming convention advice for the subclassed bo's to reduce confusion.

Something like CustMaintCustomersBO and CustMaintClientsBO ... ContrMaintCustomersBO..
but then i have a namespace like customerpropertiesgroups and one customerproperties. So i cannot name them like custprop..something because it could be confused with either one.

not sure. i have around 15 BO's in total, and not all of them are subclassed in each namespace, but still its quite alot of bo's going around.

How do you name your bo's in such cases ?

Thanks

When we do this, we place them in a different namespace.  This is something that we do for every report.  So in our medical application, we probably have the PatientsBO inherited some 40+ times for each report that uses it.  So the inherited BO is still named PatientsBO, but it will reside in a different namespace.  This reduces confusion as we know that when it is all said and done, this is going to at the very least, have all of the original PatientsBO properties.  This may not work for you, but this has been a good system for us.

hi,

am i supposed to also map my subclassed bo's in the BOM ? Because there are some properties that i can only set on the original (base) bo's and the subclassed bo's also have no .designer file.

Also, from your method, how do you prevent your toolbox to fill up with all the multiple versions of one bo ?

thanks.

Philip,



No, you don't need to map the sub-classed BOs, if you're doing it like Trent suggested. Because the report BO is sub-classed from the main BO, it will have all the functionality of that main BO. Also, if you change the underlying table, you only need to remap the main BO. All the sub-classed BOs will immediately get the changes.



The sub-classed BO just ensures that if you need to do something specific for a report, you can do it in one class and not break other reports. It also ensures that you don't have some huge, overly complex BO trying to handle everything.



As to not having these within the toolbox, you can use the ToolboxItemAttribute.











You might want them in the toolbox though, if you will be dropping them on forms.

allright. thanks.

and how do i get rid of the errors about the subclassed bos not being configured, while rebuilding the base bo's ?

thx

At this point, I don't think you do. There is a feature request in to allow the marking of a BO as one that won't be built, but that hasn't happened yet. This would be used in cases like this and also for base BOs, which also aren't built (or configured in the BO Mapper).

allright. thanks