Sibling Class

rxelizondo posted on Thursday, September 10, 2009

Hi,

I was wondering if someone could give me some advice regarding some CSLA design issue I am having.

Supposed that you have two classes with the following properties as follows:

Class Car
{
    String        Model;
    Int             Year;
    CarEngine TheEngine;
}

Class CarEngine
{
Int HorsePower;
Int NumberOfCylindes;
}

The classes above are just **make believe**, overly simplified classes to **illustrate** the issue.

In order to make my life simpler, I decided that I was going to have one table containing columns to hold all the info for the classes listed below as follows:

Table Columns:
   Model
   Year
   HorsePower
   NumberOfCylindes

And there lies my predicament. I am currently using the Car class to implement all DataPortal_XYZ methods, so when the time comes for saving the data the DataPortal_Update function on my Car class gets the values from the CarEngine class and plops them in the one table.

So I have zero DataPortal_XYZ methods on the CarEngine class and for some reason that feels somewhat disturbing to me, like if I was doing something wrong since it does not fit the template.

What do you guys thing, any one has any suggestions?

Thanks.

ajj3085 replied on Thursday, September 10, 2009

are you using DTOs to save to the database (like linq2sql classes)? If so you could use field manager and pass in the DTO so the engine can add its values.

It could also be that you could merge the car and engine classes too.. is there any reason to have them seperated?

Or you could leave things as is.. I don't inherently see anything wrong.

I realise you are just trying illistrate, but its possible in doing so you're leaving out an important detail.

OH... and at the very least... does your use case really call for having seperate objects? It might not..

JoeFallon1 replied on Thursday, September 10, 2009

I have done something similar. I have a top level BO that represents 28 of 30 columns in a table. It contains a child object that represents the other two. The child object has special code in it to store a byte array into a column in the same row. It also stores a text string related to the byte array. (Think Image and contentType.)

The top level BO does an Insert for the 28 fields and omits the other 2 fields from the SQL. The DB fields are nullable or have default values. Then the child does and Update of the newly created row but only sends the data for the two fields. It gets the rowId from the parent.

The main reason I did this is that sending a byte array to SQL Server is best done with parameterized SQL. My standard SQL is dynamic and you can;t really mix the two styles. This has worked out quite well and the top level BO is used in many places and the byte array changes to whatever is required. (Logo image, form image, etc.)

Joe