Evaluating, Running DevExpress samples


Author
Message
George Nentidis
George Nentidis
StrataFrame User (168 reputation)StrataFrame User (168 reputation)StrataFrame User (168 reputation)StrataFrame User (168 reputation)StrataFrame User (168 reputation)StrataFrame User (168 reputation)StrataFrame User (168 reputation)StrataFrame User (168 reputation)StrataFrame User (168 reputation)
Group: Forum Members
Posts: 72, Visits: 251
Hi there.

I currently evaluating the framework and I am trying to run the DevExpress samples. It seems that those are build with the DevExpress 6.3.3, while I have installed 7.1.6.

Is there a way of running them without re-installing 6.3.3?

Thank you for your time,

George Nentidis

Replies
Greg McGuffey
Greg McGuffey
Strategic Support Team Member (4.8K reputation)
Group: Forum Members
Posts: 2K, Visits: 6.6K
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!
Trent Taylor
Trent Taylor
StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 7K
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.

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.

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Threaded View
Threaded View
George Nentidis - 18 Years Ago
George Nentidis - 18 Years Ago
StrataFrame Team - 18 Years Ago
StrataFrame Team - 18 Years Ago
George Nentidis - 18 Years Ago
Trent L. Taylor - 18 Years Ago
George Nentidis - 18 Years Ago
Trent L. Taylor - 18 Years Ago
George Nentidis - 18 Years Ago
George Nentidis - 18 Years Ago
             Glad you found the property :)
Trent L. Taylor - 18 Years Ago
George Nentidis - 18 Years Ago
Greg McGuffey - 18 Years Ago
Trent L. Taylor - 18 Years Ago

Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search