Object Design - Data or IDs?

Object Design - Data or IDs?

Old forum URL: forums.lhotka.net/forums/t/1433.aspx


Crestline posted on Tuesday, October 10, 2006

Hi,

This not so much a specific CSLA question as maybe a general design question.  Thanks in advance for any suggestions...

Our data model is one that uses a lot of related IDs as a way of data validation.  Our question is, when genreating theCSLA objects, what is good practice as far as:

Loading the ID in to the object and letting the UI handle the link to the data OR having the stored procedure link the IDs to the data and only pull data into the objects?

-BR

Crestline replied on Wednesday, October 11, 2006

Does anyone have any advice?  Sorry for the newbie question....

Jav replied on Wednesday, October 11, 2006

Your question as it is asked does not appear to make any sense - at least to me.  Perhaps you can post an example.

When generating the Csla object, you have to have the ID as a part of  the object!

Crestline replied on Wednesday, October 11, 2006

A simple data desgin mock up of a couple tables and their columns

Person (table)
-personid
-name
-cityid
-countryid

City (table)
-cityid
-citymame

Country (table)
-countryid
-coutryname

So now in our app when we load the PersonObject, which way should we fill it:
A)
<sudo code>
public class Person: BusinessBase<Person>
private int _id;
private string _name;
private int _cityid;
private int _countryid;
</sudo code>
Simply load the actual IDs of City and Country (not the string names)?  This would thne require us to have name/value pairs loaded so that when the PersonObject data is presented in a Form, that the we use "name" from the pairs

B)
<sudo code>
public class Person: BusinessBase<Person>
private int _id;
private string _name;
private string _city;
private string _country;
</sudo code>
The underlying stored procedures for the Person object take care of the mapping and the object will then contain the text and no IDs at all.  This would then require all the stored procedures (select,insert,update,delete) to manage the mappings as needed.

Another question about the data design above, is this what most people use or would you change it so that the Person table would actual contain the 'text' for City and Country instead of the related table IDs?  This situation is just for an example but it shows what I'm talking about in it's simpliest form.

Thanks.



Brian Criswell replied on Wednesday, October 11, 2006

I usually load the ids for lookups and have the UI or other code resolve the lookup (through a ComboBox or IBindingList.Find()).

Crestline replied on Wednesday, October 11, 2006

Ok, this is how we normally used to do it and I just wanted to clarify that CSLA follows along this path.  Sorry for the noob question but just wanted to double check!

RockfordLhotka replied on Wednesday, October 11, 2006

So you are implementing the "Add or Edit Person data" use case? Which is probably a use case where the user is adding or editing all the data about a person?

Normally, in such a case, I would expose the city and country id values as properties from Person, not the human-readable text. The reason being that the UI will most likely make use of some sort of complex bound control (list, combobox, etc) to allow the user to select the city and country. That same data binding mechanism will automatically cause the control to display the human-readable text.

So you'll really have three classes: Person, CityList and CountryList. The latter two would be NameValueListBase-derived objects, and could be bound to a list or combobox control. Data binding does all the hard work for you.

On the other hand, the CityList might be too big. It might be unrealistic to just use a simple list or combobox control from a usability perspective. In that case you might choose to expose both the CityId and a (read-only) CityName property from Person. You can bind a Label to CityName so the user can see the selected value - and then you might give them a button so they can get a dialog to select a new city. That dialog's result would be the new CityId, and setting the Person.CityId property would trigger Person to execute a Command object to refresh the CityName property.

Crestline replied on Wednesday, October 11, 2006

Thanks Rocky.  We were heading down the name/value list road as we have done in similar situations in the past.  You basically just validated what we thought was the right way to go about it.  We have a 'company' library referenced into the app that contains a lot of these lists already...  we're good to go!

Love CSLA!



Copyright (c) Marimer LLC