Understand class instantiation

3

I have a question and would like to better understand how class instantiation works. More specifically the most appropriate way of doing (if any) and the impacts of doing the wrong thing.

Assuming these two scenarios, which one should I use and Why?

Scenario 1: Instantiating out of methods.

public class PerfilController : Controller
{
    PerfilDTO viewDTO = new PerfilDTO();
    Perfil perfilNEG= new Perfil();
    Recurso recursoNEG = new Recurso();

    public ActionResult Cadastro()
    {
        viewDTO.ListaPerfis = perfilNEG.ObterPerfis();
        viewDTO.ListaRecursos = recursoNEG.ObterRecursos();

        return View(viewDTO);
    }      

    public ActionResult Listagem()
    {
        viewDTO.ListaPerfis = perfilNEG.ObterPerfis();
        viewDTO.ListaRecursos = recursoNEG.ObterRecursos();

        return View(viewDTO);
    }      
}

Scenario 2: Instantiating within methods

public class PerfilController : Controller
{      
    public ActionResult Cadastro()
    {
        PerfilDTO viewDTO = new PerfilDTO();
        Perfil perfilNEG= new Perfil();
        Recurso recursoNEG = new Recurso();

        viewDTO.ListaPerfis = perfilNEG.ObterPerfis();
        viewDTO.ListaRecursos = recursoNEG.ObterRecursos();

        return View(viewDTO);
    }      

    public ActionResult Listagem()
    {
        PerfilDTO viewDTO = new PerfilDTO();
        Perfil perfilNEG= new Perfil();
        Recurso recursoNEG = new Recurso();

        viewDTO.ListaPerfis = perfilNEG.ObterPerfis();
        viewDTO.ListaRecursos = recursoNEG.ObterRecursos();

        return View(viewDTO);
    }      
}

NOTE: If there is a different and better way, you can also alert me.

    
asked by anonymous 25.07.2014 / 19:57

2 answers

4

As I see it:

Instantiating in the first way, when you create the object PerfilController , you will also create 3 more objects in memory ( PerfilDTO , Perfil and Recurso ) even if they are never used.

By instantiating the second form, the 3 mentioned objects will be created only when the methods are called, that is, when it is really necessary. The disadvantage is that you need to instantiate in each method (code repetition) and the objects will be created several times in memory according to the number of method calls.

What you could do (what I'm going to talk about is analysisable) is if you use the project pattern Singleton , which guarantees only one instance of a given object. Example:

private ClasseExemplo getObjetoExemplo() {
    if (objetoExemplo == null) {
        objetoExemplo = new ClasseExemplo();
    }
    return objetoExemplo;
}

And where necessary, this method should be used:

objeto.objetoExemplo = getObjetoExemplo():

So it would be guaranteed that the object would be instantiated only when necessary and only once.

I wanted to give my contribution according to what I understand, maybe other people explain more broadly and didactically than I do.

    
25.07.2014 / 20:21
2

There is a different and better way.

I recommend using the Repository to retrieve the information necessary for your Controller .

Why use it in this situation?

With this pattern you can avoid duplication of code to instantiate your objects, improve code maintenance, and other benefits such as testing.

What's wrong with getting these instances on the Controller?

It is not the responsibility of your Controller to instantiate objects such as DAT Profile, Profile, and Resource. It is the controller's responsibility to fetch data from the Model and forward the related View to view this data.

    
25.07.2014 / 20:46