Doubts about DAO, MVC, Multiple Tables and POJO

Question

If anyone can help me, I have a question q has been consuming me a lot in recent days and is psychologically locking my studies (hehehehhe) MVC and DAO with multiple tables. I’m going to put here a model, an idea and then evolve my doubts:

We imagine a system of price comparison between products that a user inserts the data to make the comparison process:

Follow the data schema, the logical model of the database:

The item table is related to Unit since the item may have different Unit of Measure.

The item table is also linked to the Compared Items table which in turn connects to Compare.

I have the table Compared Items because a comparison can be made with several items.

Follow also my packages with the classes.

Example:

Butter A - 250 g, R$3,25

Butter B - 180 g, R$ 2,80

I need to know which of the two is cheaper, so I need to know the value of every gram of butter A and B, so I’ll know exactly which is the cheapest.

My main doubts are as follows::

1 - MVC - Model, View and Controller, as well:

• Model = Are my business models as I have calculations to perform on certain items, I would have within Model a class called Comparison that will receive the objects that have relation Item - Itenscompared - Compare.

Is that really what Model’s for? I see many people putting here the objects POJO (Car, Post, Rental...)

• View = No doubt!!!

• Controller = Serves to intermediary the view with the bank (DAO). In case to use this concept on Android would it be to control the lists and insertions in the various tables that relationships need? In case I will join inside the controller_comparison for example the process of insertion of each entity and the Ids generated by the inserts I will put inside the table Compares together with the Compared Items?

2 - DAO - Data Access Object

• As I said in the MVC Model I see many people creating inside the folder model POJO objects, I believe that the correct thing would be to create a package with name POJO, VO, PO for example and create their entities there that helps in DAO, this correct I think so?

• When I create a POJO object such as Item, it has:

  public class Item {

  Integer _item_id;
  String item_descricao;
  Float item_preco;
  Float item_quantidade;
  Float item_preco_unidade;
  String item_cod_barras;
  Integer fk_unidade_medida;
  

  ... }

What is the best way to build these Pojos in relation to the connection with another entity (Relationship). I use an Integer as in the above example OR:

public class Item {

        Integer _item_id;
        String item_descricao;
        Float item_preco;
        Float item_quantidade;
        Float item_preco_unidade;
        String item_cod_barras;
        UnidadeMedida unidade_medida;

    ...
    }

Answer 1

Come on, Hugo!

Well by the description I didn’t understand, but by your modeling and the mastery of your project I think I can help you.

MVC - There is a lot of confusion, many authors talking zucchini about time and end up confusing our head. The model concerns the business rules, that includes, the pojos which is the same thing as the model, also includes the business which is where the business rules should actually be, calculations, Daos etc. The view or View is literally the pages and does not necessarily stay in the application packages. The controller or controller is a role that can be played both by you and by the application server or by the framework you are using, that is the handling of requests. Simple. But everyone creates an architecture in a way according to the understanding of these concepts.

ORM mapping - By your domain (project) I found this data model (tables) somewhat confusing. But I would: create an Item entity with the attributes id, name, establishment and price. An entity Category with id, Description and another Itenscompared with id, item, category.

So you compare the items of a category and store in the table itenscompared according to the category. I understand?

I hope I’ve helped.

Answer 2

About MVC:

• View: Views only. It is recommended to type - @model, and should never have business rules in this layer - this includes any conditional, such as if, switch, etc. If necessary, create a HtmlHelper, create your tests and then just make the call from View.

• Controller: It’s the most layer DUMB of your application. It only takes care of receiving a request, transferring the call to the Action responsible, then that Action only passes this data to other business layers to process this information. After processing, the Action Controller receive back a result and return to the View. There should not be any kind of business rule within the Action Controler, because it is not your responsibility.

• Model: Represents the entities your application will work on. Something like yours POJO's. As much as we type a View, we use the marking @model for that. So, Model represents the model entities of its application.

Model is where the rules of business are commonly said to be. But to say that is to say that View are the pages, Controller are the actions of the page and Model is all the rest.

And this is just to create your web application. The rules themselves must be built into other projects/layers, each with its own responsibility. And those other layers, it has nothing to do with MVC.

Having its layers of rules, models, infrastructure, repositories, all segregated and disabled, these can be used in a MVC application, Desktop application, UWP, Commandprompt, etc..

Something I recommend is to create a ClassLibrary for your model entities only. Another for your rules, another for repositories. All decoupled.

I have a project at Github that can serve as a model for you to get started. It’s a little dated, but it’s still a great start.

Sobre DAO:

Its model entities shall reflect reality.

public class Produto 
{
    int Id { get; set; } 
    string Descricao { get; set; } 
    UnidaDeMedida UnidadeDeMedida { get; set; }
    decimal Quantidade { get; set; } 
    decimal PrecoPorUnidade { get; set; } 
    string CodigoDeBarras { get; set; } 
    // ...
}