Mapping normalized database tables to classes

Question

I'm developing a simple online ordering application and already have a database schema design that uses normalization.

Among others, there are 3 tables: order , product and order_d (meaning order details).

These are the classes that map to the tables (I'm using PetaPoco as my ORM):

public class order {
    [PrimaryKeyColumn]
    public int o_id { get; set; }

    // order info
}

public class product {
    [PrimaryKeyColumn]
    public int p_id { get; set; }

    // product info
}

public class order_d {
    [PrimaryKeyColumn]
    public int od_id { get; set; }

    [ForeignKey(typeof(order), Column = "o_id")]
    public int id_order { get; set; }

    [ForeignKey(typeof(product), Column = "p_id")]
    public int id_product { get; set; }

    public int product_quantity { get; set; }
}

Now, when I want to display an order on the front end I have to get records from the order and order_d tables and join them on a single object/entity: an Order, which we can say is the domain model (correct me if I'm wrong please:P).

In my mind, it looks something like this this .

I've been reading about the repository pattern and, as I understood it, applying it to my project would look something like this .

I have a few questions about this:

• Is it the right solution for this problem?
• What do I have to implement on my project to make use of this pattern?

Hope I didn't oversimplify anything. Thanks.

Answer 1

The way I see it, you don't have to join Order and Order_d tables, your ORM should do that instead. The Order object that you'll get this way, will be a domain model or at least consistent with it, so if the Order in your domain has non-persistent properties or additional behavior you could consider creating a partial class for those parts.

I don't think you need a repository pattern implementation, as you don't mention a real need to separate data access from domain logic. Remember your data access is provided by your ORM and so anything you do with those objects after you used your ORM won't make too much sense. I honestly don't believe you have a good candidate to implement this pattern. If you want to jump between different ORMs well that's another story.