Questions about DAO, MVC, Multiple Tables and POJO

Question

Questions about DAO, MVC, Multiple Tables and POJO

Navigation

#1 by (1 votes)
#2 by (1 votes)

9

If someone can help me, I have a question that has been consuming me a lot in recent days and is psychologically locking my studies (hehehhe) MVC and DAO with multiple tables. I will 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:

Here is the data schema, the bank's logical model:

ThetableitemhasrelationtoUnitsincetheitemcanhavedifferentUnitofMeasure.

TheitemtablealsobindstotheComparedItemstablewhichinturnbindstoCompare.

IhavetheComparedItemstablebecauseacomparisoncanbemadewithseveralitems.

Italsofollowsmypackageswithclasses.

Example:

Butter A - 250 g, $ 3.25

Butter B - 180 g, $ 2.80

I need to know which one is cheaper, so I need to know the value of each gram of butter A and B, so I'll know exactly which one is the cheapest.

My main doubts are as follows:

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

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

Does Model Really Work? I see many people putting here the objects POJO (Car, Post, Rental ...)

View = I have no doubts !!!
Controller = Serves to intermediate the view with the bank (DAO). In the case of using this concept on Android would it be to control the lists and insertions in the various tables that relationships need? In the case I'm going to join in the controller_comparacao for example the process of insertion of each entity and the IDs generated by the inserts I'll put it inside the Compares table along with the Compared Items?

2 - DAO - Data Access Object

As I mentioned in the MVC Model I see a lot of people creating POJO objects in the model folder, I believe the correct thing would be to create a package named POJO, VO, PO for example and create their entities there, this helps 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 linking to another entity (Relationship). I use an Integer as in the above example OU:

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;

    ...
    }

java mvc pojo

asked by anonymous 30.11.2015 / 20:45

2 answers

Demoiselle JUnit - NullPointerException Where does Git pull point?

score 1 · Answer 1

Come on, Hugo!

Well by the description I do not understand, but by its modeling and the domain of your project I think I can help you.

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

ORM Mapping - For your domain (project) I find this data template (tables) confusing. But I would do so: I would create an Item entity with the attributes id, name, establishment and price. An entity Category with id, description and other Items Compared with id, item, category.

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

I hope I have helped.

score 1 · Answer 2

About MVC:

View : Views only. It is recommended to be typed - @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 : This is the most BURRA layer of your application. It only takes care of receiving a request, transferring the call to% responsible%, then this Action only passes this data to other layers of business to process this information. After processing, the Action Controller returns a result and returns it to the View. There should not be any type of business rule within the Action Controller , as it is not your responsibility.
Model : Represents the entities that your application will work with. Something like your POJO 's. So much so that as we type a View , we use the Action tag for this. Then Model represents the model entities of your application.

Model is where it is commonly said that business rules remain. But to say this is the same as saying View are pages, Controller are page actions and Model is everything else. p>

And that's just for creating your web application. The rules themselves should be built into other projects / layers, each with its own responsibility. And those other layers, have nothing to do with MVC.

Having its layers of rules, models, infrastructure, repositories, all segregated and deployed, these can be used in an MVC application, Desktop application, UWP, CommandPrompt, etc.

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

I have a project on GitHub that can serve as a template for you to start . It's already a bit dated, but it's still a great start.

About DAO:

Your model entities should 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; } 
    // ...
}