Object Design Question - Please help

white911 posted on Monday, June 11, 2007

I am still using CSLA 1.6, since I did not upgrade yet to VS2005.

I have a question about object design.

I have a supertype table Person and a 2 sub type tables (customer, vendor). The Table Person has a auto generated field (PersonID), and the subtype tables PK refer to this field.
Customer: CustomerID --> PersonID
Vendor: VendorID --> PersonID

When I look at my behaviours, I have the following requirements.

Add a new customer

Add a new vendor

How do I setup the objects. I know I need a Customer object and a Vendor Object. However, where do I add the person data (address etc.) which is part of each object? Do I create a Person object and inherit from it? Or do I repeat it in the Customer and Vendor Objects? And how to I save the person data to it's table (same stored procedure)

RockfordLhotka replied on Tuesday, June 12, 2007

Objects should be designed based on the responsibility and behaviors they need in order to do their job. Their job (responsibility) is defined by a use case. In other words, don't focus so much on the database structure when designing your objects.

In a typical "add/edit a X" use case you have the following objects for that use case:

• XList - read-only list of XInfo
• XInfo - read-only child
• XEdit - editable root
• Assorted name/value lists to populate comboboxes

In your case, both CustomerEdit and VendorEdit would have some common properties, but that's OK. That is an artifact of the relational world, and really doesn't (shouldn't) impact your object design.

It does mean that DataPortal_Insert() will have to do two inserts, but that's unavoidable no matter how you implement your system - it is a side-effect of data normalization.

However, don't forget about normalization of behavior in your object model. It will almost certainly be the case that both CustomerEdit and VendorEdit need to insert (and update) data in the Person table. That code will almost certainly be the same. Thus you should normalize that behavior into a third object (probably implemented with static/Shared methods) to do that common work.

So for "Add/edit a customer":

• CustomerList - read-only list of CustomerInfo
• CustomerInfo - read-only child
• CustomerEdit - editable root
• Assorted name/value lists to populate comboboxes
• PersonEdit - internal/Friend class with static/Shared methods to insert/update/delete data, and to contain any common rule method implementations

Notice that rule methods common to both CustomerEdit and VendorEdit are also normalized into PersonEdit. PersonEdit is not an editable root - it is almost certainly a static class or Module. It is only an "object" from a design perspective. From an implementation perspective it is merely a tightly cohesive set of methods.

white911 replied on Thursday, June 14, 2007

Hi Rocky,

Thanks for replying.

I am confused how to setup the PersonEdit object. From which object should I inherit it in order to use CSLA data portal?

RockfordLhotka replied on Thursday, June 14, 2007

white911 replied on Thursday, June 14, 2007

So why did you write in the previous post that Person Edit is not a editable root.

Sorry for my confussion

RockfordLhotka replied on Thursday, June 14, 2007

Wal972 replied on Thursday, June 14, 2007

Would the same principle apply if the set up was

Person (table)

-> Addresses (Sub Table)

-> Contacts (Sub Table)

-> Vendors (Sub Table)

-> Customer (Sub Table)

Because a customer would have one link to the Person table which in tern could have multiple addresses and contacts

Assistance would be appreciated

Ellie

RockfordLhotka replied on Thursday, June 14, 2007

It is impossible to say what objects are required based on a set of tables. Objects exist to fill roles within a use case.

If more than one object has the same behavior (like a common business rule, algorithm, etc) then you need to normalize that behavior into another object, so the original objects can collaborate with this new object to get at the behavior.

This is typically very easy to do within the context of a use case, because you are designing all the objects at the same time for any given use case.

It is harder across use cases, because you may design them at different times, or in a team setting you may be unaware of other use cases being designed. This, in my view, is where cross-pollination, code reviews and refactoring come together. Cross-pollination and code reviews offer the opportunity for developers to see each other's designs and implementation, and refactoring provides a "blessed" approach to normalizing behavior after the fact (after the fact for at least one use case implementation anyway).

Wal972 replied on Thursday, June 14, 2007

To clarify, I mean I have a use cases of CustomerEdit & VendorEdit, in which you can

Edit the customer, including their addresses and/or contacts.

Edit the vendor, including their addresses and/or contacts.

Would the common action of editing the addresses and/or contacts. be separated into a static class/module ?

Thanks

Ellie

RockfordLhotka replied on Thursday, June 14, 2007