What is the correct MVC concept to be addressed?

Question

I’m working on an Laravel project with the concept MVC and I had some doubts.

Let’s say I have one customer management (CRUD), so I have a View (Screen with customer data, Textbox, Combobox ...) I have one Controller, where I pass the screen information to the Controller and it is responsible for chatting with my Model responsible for managing the object by recording in the database among other things ...

For example, in a Client, Functionary and Address soon it is possible to view that 1 Customer or Employee can have multiple Addresses, and this model would be

• 1 Customer has several or no Address
• 1 Employee has several or no Address

Tables

Client: idc, name, Cpf.

Official: idf, name, post, post, post.

Address: id (where the Customer and Employee Id enters as PK), type (To find out if you are customer or employee), zip code, city, state.

Doubt 1) In the model in question I would have to create a Controller for Address or only for Customer/Employee and they would already make direct contact with the Address Model? Or else I would have to create an Address Controller and the Employee/Customer Controller would have to access the Address Controller and it would bridge to the model?

Doubt 2) This model is correct?

Doubt 3) Would it be better if I create a separate address table? ie Address, Address ?

Answer 1

Good morning I would do so, create an Address class, a Contact class, and one of each table in the database, I will use these two examples because you can use where you want.

In the Endereco class will have the fields idEndereco, idDonoEndereco, idTipoEndereco, cep, patio, numero, complement, bairro, municipio, Uf.

in the Contact class you will have the following fields: idContact, idDonoContact, idTipoContact, Telephone(if you need to create a phone table), e-mail, etc.

in your customer class you will be able to retrieve the address and contact details using the following command:

    public class Clientes
{
   // coloque os campos necessarios
    public Endereco Endereco { get; set; }
    public Endereco EnderecoEntrega { get; set; }
    public Endereco EnderecoCobranca { get; set; }
    public Contato Contato{ get; set; }

}

use this code in seller table, Vendor, Employee, etc.

on your layer saved in the database you can use the idDonoEnderecho and type:

Client: Iddonoenredeco = "The client id" idTipoEndereco = "1 or 2 or 3", 1 Addressee, 2 Addressee, 3 Addresswhite.

Supplier: idDonoEndereco = "supplier id" idTipoEndereco = "4", 4 is from supplier

seller: idTipoEndereco = "5", the 5 is from the seller.

and so on when doing the select picks up the idDonoEndereco and the idTipoEndereco you will have the address data is the same logic for the contact, and phones.

so you use a single address table for all entries.

hope I’ve helped

Answer 2

MVC is nothing more than a standard software architecture, separating your application into 3 layers. The layer of interação do usuário(view), the layer of manipulation of dados(model) and the control layer(controller).

Model

Whenever you think about data manipulation, think about model. It is responsible for reading and writing data, and also for its validations.

View

Simple: the user interaction layer. It just displays the data, being it through an html or xml.

Controller

The person responsible for receiving all user requests. Its methods called actions, are responsible for a page, controlling which model to use and which view will be shown to the user.

Answer to question 1:

That depends !! I will explain

If you have a screen only for address the correct would be to have one controller address only. On the other hand, if the entity endereço is created together with the Funcionário/Cliente that is it depends on the entity the best in that controller for Funcionário where would bridge to the model endereço. When you separate the responsabilidades você tem o ganho de coesão what’s good for a project alta coesão e baixo acoplamento between classes speaking in POO.

Take a look at these concepts of cohesion and coupling.

What are the concepts of cohesion and coupling?

Doubt 2) This model is correct?

Is this model correct? There is not always something correct or better for all cases. You have to analyze the Real way to see what looks best for each case or project. Plus the model MVC for this Case study is a good option.

Doubt 3) Would it be better to create a separate address table? ie EnderecoCliente, EnderecoFuncionario, Cliente, Funcionario ?

The right or better in this case is you create a single tabela endereço for cliente and funcionário. This would avoid data redundancy because you can have the same address in two places which would produce redundancy and also increase the complexity and maintenance of your project.

Example :

Cliente has 1 or N endereços.

Funcionário has 1 or N andaddresses`.

Answer 3

Good night...

so I understood the question and the very detailed answer by our colleague...

the main question is about data modeling and not mvc (specifically); the bigger question is data integrity, the sense of mvc or why or sets should be(too) based on DRY,(Don t repeat yourself).

a table address only, solve well, based on this table you can access any field, PK or FK.

And about the business model of this project, I don’t think it’s ideal Functionary or Client without address, for the future of data analysis.

hope to have generated more subject for research and case study, a hug.