Question on OO best practices with Foreiqn keys

[BillG]

I have pondered this question often and have done it several ways but I am
wondering what is the correct OO way to handle this.

In my SQL Sever database I have the following tables for example,

Member and MemberStatus

Member status has two fields StatusCd and Description. ex. 'A' and
'Active', 'I' and 'Inactive'

Member has a field called Status that tracks the status of that member.
What is the proper way to create this class?

public class Member
{
private string m_SocSecNo;
private string m_LastName;
private string m_FirstName;
(A) private string m_StatusCd or

(B) private MemberStatus m_MemberStatus

(C) private string m_StatusCd;
private string m_StatusDescription;

}

public class MemberStatus
{
private string m_StatusCd;
private string m_Description;
}


Thanks
Bill

 

[Jon Skeet [C# MVP]]

I have pondered this question often and have done it several ways but I am
wondering what is the correct OO way to handle this.

In my SQL Sever database I have the following tables for example,

Member and MemberStatus

Member status has two fields StatusCd and Description. ex. 'A' and
'Active', 'I' and 'Inactive'

Member has a field called Status that tracks the status of that member.
What is the proper way to create this class?

How many possible statuses are there? I would probably either use an
enum for the MemberStatus, or a class but with a private constructor
and a few predefined immutable values (so that you can still have both
the code and the description).

I certainly wouldn't put them both in Member.

 

[BillG]

There could be 5 or 6 different statuses and I don't necessarily know what
they are. They could be different for different clients so I can't create
an enum. This is also just an example. It could be a case like this

public class Customer
{
private int m_Id;
private string m_CustomerName;
private string m_SalesPersonId;

or

private SalesPerson m_SalesPerson;

}

public class SalesPerson
{
private string m_Id;
private string m_LastName;
private string m_FirstName;
private string m_Telephone;
}

 

[Jon Skeet [C# MVP]]

There could be 5 or 6 different statuses and I don't necessarily know what
they are. They could be different for different clients so I can't create
an enum.

Ah, rats. Ah well - it would save memory to have a fixed set of
flyweights, but loading them isn't too bad.

This is also just an example. It could be a case like this

public class Customer
{
private int m_Id;
private string m_CustomerName;
private string m_SalesPersonId;

or

private SalesPerson m_SalesPerson;

}

I'd prefer a proper class reference, again.

 

[Cor Ligthert[MVP]]

Bill,

Why are you not just using booleans (bit in SQL server)?

Seems for me to make it difficult especially to maintain not using the right
types for the meant purposes.

Cor