Varied behavior based on datatype

esteban404 posted on Friday, July 14, 2006

I have a collection of line items of types Sales Order, Purchase Order and Invoice. I need to use all three in multiple locations.

The collections have items with a parent ID and number included. Worked fine until another BusinessBase class came along whose primary field was not the same type. I now have two objects (BusinessBase 1.53) which do not have the same data type for their ParentID: one uses a Guid, the other a long.

Is a criteria object sufficient to choose the correct CRUD actions or do I need more than one object?

Thanks in advance,

esteban404 replied on Friday, July 14, 2006

The objects are not the same object. The collection being returned is the same but the object(s) that needs the filled collection have different datatypes for their ids. I need the collections to be reuseable by other classes so they can get the same data from our data warehouse.

I *will* need a new table to store these values, but I think I one class can fill the collections. I erred in saying the behaviour is different... it's not, only some criteria changes. That's easy enough.

I jumped the gun. (Though the sky does look to be falling today.)

vargasbo replied on Monday, July 17, 2006

If you have different behavior, then you should have two different object collections. Csla kinda prevents you from have a generic type of collection, which is what it seems you want.

Tom Cooley replied on Monday, July 17, 2006

You can overload your factory methods to take the different data type parameters. You probably want to have two criteria classes nested in your collection and your dataportal methods will react accordingly based upone which one is received. In this case you, may want to inherit from CriteriaBase so that can be the type for the parameter on the dataportal methods. Then cast to the GuidCriteria or IntCriteria to get at the properties nested within.

Another consideration is to alter the table schema for one of the root objects so that they match. One column is the primary key and the other becomes a candidate key. So long as they are both unique, they are both candidates for obtaining the right record(s). It might sound unconventional but if you make a table with an int primay key replicable, it would do the exact same thing.

esteban404 replied on Monday, July 17, 2006

I broke down and just mapped all the fields involved and made an abstract class to contain the common fields. It turned out the storing database had multiple programmers who called the same type of data by different names and datatypes. I've poured them into a common cup and the DataPortal code handles each one and converts the datastore to a more reasonable value.

I think that contributed to how difficult it appeared to be.