What is the correct MVC concept to be addressed?

Good morning I would do so, I would 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 wherever you want.

In the Endereco class you will have the fields idEndereco, idDonoEndereco, idTipoEndereco, cep, logradouro, number, complement, neighborhood, municipio, uf.

In the Contact class you will have the fields: idContact, idContact, idContact, Phone (if necessary create a phone table), email, etc.

In your client class you can take the contact and address data 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 the vendor, vendor, employee, etc. table.

In your layer that saves in the database you can use the eDirectory and eDirectory for example:

Client: IDDonoEnredeco="The client id"           idTipoEndereco="1 or 2 or 3", 1 Address, 2 AddressDelivery, 3 AddressCobranca.

Vendor: idDonoEndereco="the vendor id"             idTipoEndereco="4", the 4 is from the vendor

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

and so on when you do select pick up the idDonEndereco and the idTimEndereco 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.

I hope to have helped

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

Model

Whenever you think of data manipulation, think of model. He is responsible for reading and writing data, as well as for his validations.

View

Simple: the user interaction layer. It just displays the data, either by means of an html or xml.

Controller

The 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 doubt 1:

That depends !! I'll explain

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

Take a look at these concepts of cohesion and coupling .

O What are the concepts of cohesion and coupling?

Doubt 2) Is this template correct?

Is this model correct? There is not always something right or better for all cases. You have to look at the real case to see what works best for each case or project . Plus the MVC template for this case study is a good option.

Doubt 3 ) Should I create a separate address table? or EnderecoCliente , EnderecoFuncionario , Cliente , Funcionario ?

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

Example:

Cliente has 1 or N endereços .

Funcionário has 1 or N and addresses'.

Good evening ...

I understood the question and the very detailed answer from our colleague ...

The main issue is about data modeling and not mvc (specifically); the biggest issue is data integrity , the meaning of mvc or poo or sets should be (also) based on DRY , (Don't repeat yourself).

A table address only, resolves well, based on this table you can access any field, PK or FK < strong>.

And about the business model of this project, I do not believe that a Official or Client without address is ideal, even in the future data analysis.

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