Modeling Classes Based on Table Designs

Question

Is this how one would normally design classes? One class = 1 Table. How about tables that contain a foreign key to another table?

Suppose I have the following:

PersonTable
---------------
person_id
name

PersonMapTable
---------------
map_id
type_id (fk)
person_id

PersonTypeTable
-------------------
type_id
description
parent_type_id

AddressTable
-------------------
address_id
address1
address2
city
state
zip

AddressMapTable
-----------
address_map_id
address_id
person_id

Would good practice consist of creating a class for each table? If so, what are the best practices for loading/saving such classes back to the database without an orm? A simple code example would be really helpful

Answer 1

I'd recommend reading Martin Fowler's Patterns of Enterprise Application Architecture, which has several patterns of mapping between classes and tables.

Answer 2

I don't think that one object per table is necessarily a good design. It's hard to give a one size fits all rule, but objects can be richer and more fine grained. A database can be denormalized for reasons that don't apply to objects. In that case, you'd have more objects than tables.

Your case would include 1:1 and 1:m relationships:

public class Person
{
    // 1:m
    private List<your.namespace.Map> maps; 
}

public class Map
{
    // 1:1
    private your.namespace.Type;
}