MVP - Model Layer Architecture - Where and how to Setup Entities and DAO

Question

I'm coding a "small" application using MVP pattern that gets it's data from a SQL database.

I'm not using an ORM out of the box, and for the sake of learning, I'm writing my own simple ORM/DAO type of setup. I'm utilizing some of the ideas from ormlite

With regards to the model layer, Here's where I'm at:

• DatabaseObject:(connects to database, and executes sql commands, returns results from sql queries)
• DAO(bridges an entity to the database.) builds the query from the entity and executes it with the database object)
• Entity(the business thing with properties that represent a column in the database)

My question lies in the DAO/Entity Part and what's the right approach.

1. Could/Should the DAO be injected into the entity? E.g. Customer.DAO.Create vs CustomerDAO(Customer).Create
2. With database relationships(E.g. Customer and Orders) Should the Customer Entity(Customer) contain an array/collection property of Customer's Orders? How should this affect question 1? The Order DAO is now nested in a Customer. Is this the right way?
3. Presenter: If I understand correctly, the presenter is "heart" of the design. It will handle the UI logic AND could do business logic calls and access to the data via the model layer? E.g. the UI calls a save method in the presenter(pseudo code):

---

Save()

{
model.LoadFields(view.GetFields)
modelDAO.Save(model)
}

and this Load action in the presenter

    LoadCustomer()
{
    modelDAO.Load(modelID, model)
    orderDAO.Load(modelID, model.orders)
    view.field1 = model.field1
    view.field2 = model.field2
    view.field3 = model.field3
    view.fillOrdersListBox(model.orders)
}

Is the above a "good" direction?

Answer 1

1. No, it is my opinion that the equivalent of Data access objects would belong in the Presenter. The Presenter updates the Model in MVP. This comes from my experience coding in C# using MVC. In MVC, database and model instantiations are performed in the Controller class.

2. Yes, your Customer model needs an array of Orders property. The effect is on how you use the model. Your model is a definition of the data and wouldn't be the place for the DAO. A good example of this is the Microsoft MVC music store DB

   namespace MvcMusicStore.Models { using System.Collections.Generic; public class Genre { public int GenreId { get; set; } public string Name { get; set; } public string Description { get; set; } public List<Album> Albums { get; set; } } }

3. You got it. The Presenter is usually the "Heaviest" part of the pattern.

Note: I took the above code snippet from: https://docs.microsoft.com/en-us/aspnet/mvc/index