Glad you found the property

Since we're working more and more with the framework, more complex issues arise.

Is there a nice way of implementing inheritance between BOs? For instance could we have a Customer BO and an Employee BO both having a Contact BO as a parent? It would save redundant code and BOs.

For instance a Contact could have multiple addresses. So we need a Contact BO and an Address BO connected with owner-child relationship. A Customer could also have multiple addresses. So we need another Address BO to connect it with the Customer BO. If we need to implement this with Employees too, then we would need  a third Address BO to connect it with the Employee BO. This would result in three Address BOs having the same implementation.

But if both Customer and Employee have Contact as their parent, then we would need a single Address BO, connected with the Contact BO, and inherit this connection.

 

So, do you think this inheritance between BOs is possible?

 

Thank you for your time...

George Nentidis

My first thought is that you'd do this at the db level. I.e. generalize you table design. Then, you'd just have a straight forward translation of tables to BOs. I'll be interested to see if there are other ways of handling this though!

Yes, this is definitely possible and also recommended in many cases.  However, in this example I would take a different approach.  In our medical application, we have the same need.  We have patients, insurance carriers, service facilities, etc. wll that have the need for unlimited phone numbers and others with the need for multiple addresses.  In this case you are better off creating a table called PhoneNumbers and another called Addresses (you could combine them if you need to).  Then create a type field that is represented by an enum in the BO.  This way you can have as many addresses and phone numbers for as many different tables that are necessary.  You can then create a custom property on each of the BOs that returns the primary phone/address, secondary phone/address, etc.  This is a much cleaner avenue to travel.

You can then create a base BO that all of theses BOs can inherit that has the logic to pull the address/phone number from the PhoneNumbers and Addresses table so you only have to program this logic once.

Example Phone Numbers Table Structure

ph_pk - BigInt (Primary Key)
ph_ParentPk - BigInt (Parent Foreign Key)
ph_ParentType - Int (Determines the parent table type - Patients, Customers, Carriers, etc.)
ph_Type - Int (Home, Work, etc.)
ph_Rank - Int (Allows the end-user to rank the phone number in order of most reachable)
ph_PhoneNumber - VarChar (Phone Number)

(I think that you get the idea)

Then create a base BO that each of these inherit that implements the logic to pull from this table:

Very Simple Example of a Base BO

Public Class MyBaseBO
     Inherits MicroFour.StrataFrame.Business.BusinessLayer

Public Property PrimaryPhoneNumber As String
    Get
        '-- Place your logic to pull from the Phone Numbers Table
        Using bo As New PhoneNumbersBO
            '-- Retrieve the TOP phone number
            bo.FillWithPrimaryPhone(parentType, primaryKeyOfParentRecord)

            If bo.Count > 0 Then
                Return bo.ph_PhoneNumber
            Else
                Return String.Empty
            End If
        End Using
    ENd Get
    Set (ByVal value as String)
        '-- Parse the passed string and update the Phone Numbers table (if necessary...you can also make this property
        '    read-only so that it only supports the Get
    End Set
End Property

End Class

Inherit off of that BO

Public Class Customers
    Inherits MyBaseBO

End Class

Note: When you change the inherits of a BO, just change it in the main file (MyBo.vb) and not the designer file (MyBo.Designer.vb).  The inherits is only in the main file so that when the BO Mapper builds the partial class, it doesn't override the inherits statement.