Olá Renan,
De fato as duas soluções são equivalentes neste caso específico. Geralmente, damos preferência para a segunda abordagem (a que recebe o contexto como parâmetro) pois ela permite a configuração do nosso UsuarioDAO.
Um exemplo seria a situação onde precisássemos escrever uma classe para testar a classe UsuarioDAO. Como só queremos testar o DAO, não faz sentido criar uma conexão de verdade com o banco de dados para testá-lo pois estamos utilizando um framework pronto e sabemos que ele funciona. Só precisamos testar a lógica do DAO. Na primeira abordagem, estamos instanciando o contexto no construtor do DAO. O problema disso é que o contexto sempre vai trabalhar com um banco de dados de verdade mesmo em um ambiente de testes!
Para evitar isso, podemos criar um contexto fake que se comporta exatamente igual ao contexto do Entity mas que não faz acesso a um banco. Ele poderia simplesmente guardar os dados em memória, por exemplo. Com esse contexto fake pronto, só precisaríamos fazer o nosso DAO utilizá-lo... mas como podemos fazer isso se ele sempre instancia o EntidadeContexto no construtor? Precisamos alterar o construtor para que possamos passar para ele o contexto que queremos que ele utilize!
Com isso na segunda abordagem, nosso DAO simplesmente pede um contexto no construtor. Se esse contexto é de verdade ou de mentira não faz diferença prá ele. Se quisermos testar o DAO, podemos instanciar um contexto de testes e passar esse contexto no construtor do DAO. Se quisermos usar o DAO em produção com um banco de verdade, basta instanciar um contexto de verdade e passar no construtor, beleza?
Essa ideia de fazermos nossas classes pedirem tudo que elas precisam para funcionar chamamos de inversão de controle. A classe não tem controle sobre as suas dependências, elas precisarão ser fornecidas sempre que a classe precisar ser utilizada. O ato de fornecer as dependências de uma classe é o que chamamos de injeção de dependências.
Espero ter esclarecido sua dúvida!
