More design questions..

ajj3085 posted on Thursday, August 10, 2006

I'm building editable objects for modifying a product database.

I have two seperate root objects; Product and ProductBundle.  There's a common interface between them (although I'm not sure its needed.. I'll likely take this out).  The main difference is that a product bundle includes a list of products and different rules for what is an acceptable product number, and has an option for how the price is set (fixed price, or the sum of the prices of the consitutent products).

Its the list and UI I have some questions about.

The list itself may have an existing product added or removed, however the items IN the list are not editable.  I'm thinking that the ProductInfo class (a read-only class) could be acceptable; the information displayed would be the same here as any other place ProductInfo would be used to display read-only Product information.  So is the answer to build a new kind of BusinessListBase, which allows only readonly objects (the current BLB only allows IEditiableBusinessObjects)?

Onto the UI; the form would be mostly the same.  The only difference would be a grid for the bundle's products and the option on how to set the price.  So should I use the same form, which can handle either?  Or should I just build two distinct forms?

Thanks
Andy

JHurrell replied on Friday, August 11, 2006

Andy,

There's a pattern I use when I have to establish relationships or associations between an object and other objects.

In my case, it's usually users and roles. I like to use UI where you have two lists. One list displays the roles that are associated with a user, the other list displays the roles that are not associated with the user. In between the two lists are the typical >, >>, <, << buttons that allow you to associaciate/disassociate the selected, or associate/disassociate all. (I've attached a screenshot as an example).

The properties of each of the items includes it's ID, a friendly text description, and a bool that indicates whether it's associated with the parent (true) or not (false). I create two filters and bind the filtered list to the appropriate ListBox.

When each child saves, it just calls an Update procedure if dirty and the procedure will create or delete the association.

I've found that users really like this type of pattern for creating the kinds of associations that we're both talking about. It's very easy to use and understand and it's pretty simple to program.

The trickiest part is the SQL that you'd write to retrieve the product associations. Assuming that you have a Products table and a ProductBundles table, the SQL could look something like this:

CREATE PROCEDURE [dbo].getProductAssociations
(
    @ProductBundleID AS INTEGER
)
AS
SELECT
    Products.ProductID,
    Products.ProductName,
    CASE
        WHEN ProductBundleID = @ProductBundleID THEN CAST(1 AS BIT)
        ELSE CAST(0 AS BIT)
    END AS Associated
FROM
    Products
    LEFT OUTER JOIN ProductBundles
        ON Products.ProductID = ProductBundles.ProductID
        AND ProductBundles.ProductBundleID = @ProductBundleID
ORDER BY
    Products.ProductName
GO

Anyway, just wanted to offer my idea.

- John