Enviar email pelo .Net

No framework 2.0 para cima, você pode usar a classe SmtpClient para enviar um email em sua aplicação. Veja o código abaixo:

// Cria o cliente Smtp passando o endereço e porta do host
SmtpClient client = new SmtpClient();
client.Host = "smtp.seusitedeemail.com.br";
client.Port = 25;

// Passa o usuário e a senha se o servidor SMTP requer autenticação
client.Credentials = new NetworkCredential("usuario", "senha");

// Cria a mensagem a ser enviada
MailMessage msg = new MailMessage();
msg.From = new MailAddress("fulano@email.com.br", "Fulano");
msg.To.Add(new MailAddress("email1@provedor.com.br", "Destinatário 1");
msg.To.Add(new MailAddress("email2@provedor.com.br", "Destinatário 2");

msg.Subject = "Assunto da mensagem";
msg.Body = "Corpo da mensagem";

client.Send(msg);

P.S: Se estiver usando o framework 1.1, tente esse link :

http://msdn2.microsoft.com/en-us/library/system.web.mail.smtpmail(VS.71).aspx
Nunca usei essa classe, mas parece atender às necessidades.

DataReader vs Dataset

Lá vai eu mais uma vez tentar ressuscitar esse blog. Vamos ver se dessa vez eu consigo :)

Um tema clássico em artigos sobre .Net é a rapidez do DataReader em comparação com o Dataset carregado por um DataAdapter. Isso realmente é verdade, mas não significa que você deva substituir todos os Datasets de sua aplicação por datareaders. Dependendo da forma que está utilizando o DataReader, ele pode ter a mesma performance que um DataSet*.

Primeiro é preciso entender porquê o DataReader é mais rápido que um DataSet*. A vantagem do DataReader consiste no fato de não precisar carregar todo o conteúdo da tabela em memória, e de retornar os registros à medida que são disponibilizados pelo banco.

Quando se usa o DataSet*, todos os registros retornados são carregados em memória, para depois serem processados. Já o DataReader carrega na memória apenas o registro atual, diminuindo assim os custos de memória da aplicação. Dessa forma, porém, não é possível acessar registros anteriores.

Outra vantagem é que o DataReader retorna os registros coforme forem sendo disponibilizado pelo banco, enquanto o DataSet aguarda o término da execução da procedure para prosseguir a execução, ou seja, a aplicação ficará parada enquanto isso.

Entretando, se você estiver usando o DataReader para ler todos os registros do banco e carregá-los na memória (Que é exatamente o que o DataAdapter faz, pois ele usa um DataReader) para então processá-los, estará anulando as duas vantagens do DataReader. Nesse caso seria melhor usar um DataSet, que teria a mesma performance e requeriria menos código.

Ou seja, um DataReader só será vantajoso se você carregar na memória apenas um registro de cada vez, e processar os registros um a um, conforme os ler do DataReader.

* - Sempre que eu mencionar o DataSet nesse artigo, como em "performance do DataSet", entenda que estou falando não só do DataSet, mas do processo de usar um DataAdapter para carregar os registros do banco em um DataSet.

Um Try..catch em cada método

Muitos desenvolvedores acham que o ideal é colocar um try...catch em todo método. É comum ver blocos assim :

try
{
{Código}
}
catch(Exception ex)
{
throw ex;
}

No exemplo acima, o try .. catch é inútil, pois o efeito seria exatamento o mesmo, caso não se usasse try.. catch. Nos dois casos, quando um erro ocorresse, esse erro seria lançado para o método superior, a diferença no caso do exemplo acima é que o erro seria lançado duas vezes, uma na origem do erro e outra no comando throw ex.

A própria Microsoft recomenda que o catch seja utilizado apenas quando alguma coisa for feita com a exceção, ou seja, quando a presença do try..catch fizer alguma diferença. Caso contrário será uma sobrecarga desnessária.

Concordo que seja necessário tratar todos os erros, mas isso não precisa ser feito em todas as funções, se você tratar o erro nas funções principais, os erros das subrotinas também serão capturados.

Classe ReadOnlyCollection

Recentemente tive um problema que outros já podem ter tido.

Tinha uma classe com uma coleção (List<>) private que queria disponibilizar, mas queria que quem utilizasse a classe pudesse apenas ler o conteúdo da lista, sem alterá-la. Se eu simplesmente colocasse uma propriedade pública com a lista, ia permitir que alguém adicionasse ou removesse elementos dela.

Entre outras soluções que pensei para isso, descobri uma classe que ajuda bastante. A ReadOnlyCollection. Ela é na verdade um Wrapper para uma coleção. Vamos supor que você tem uma lista de string na sua classe:

private List _linhas;

Para publicá-la como somente leitura , use :

public ReadOnlyCollection Linhas
{
get { return new ReadOnlyCollection (_linhas); }
}

Vale lembrar que esse método não duplica o conteúdo da lista. Como a classe é apenas um wrapper, qualquer alteração no conteúdo da lista será refletida no objeto ReadOnlyCollection já criado.

Classe ControlPaint

Uma classe interessante para quem está trabalhando com controles Owner Draw, ou seja, desenhando na mão o conteúdo do controle, é a ControlPaint.

Ela possui métodos para facilitar o desenho de controles, como o método DrawBorder3D (Acho que não preciso dizer que esse método desenha uma borda em 3D) e métodos para desenhar botões, checkboxes etc.

Breakpoints Avançados

O tradicional Breakpoint, usado para interromper a execução do sistema e permitir a depuração do sistema possui algumas opções que podem ajudar bastante.

Você já teve que depurar algum loop e ficar apertando F10 até chegar na iteração que está dando problema? Você pode configurar o breakpoint para interromper a execução somente na n-ésima vez que passar por ele. Para isso, clique com o botão direito em um breakpoint existente (Clique na bolinha vermelha) e vá em "Hit Count...". Existem algumas opções para parada, uma pra parar quando o número de passados pelo breakpoint atingir um determinado valor ou for múltiplo de um determinado número , por exemplo.

Outra opção interessante é "Condition..." , acessada do mesmo popup menu, que permite que estabeleça um condição para que o Breakpoint pare. Você pode, por exemplo, fazer com que o breakpoint pare quando um totalizador atingir determinado valor, colocando uma expressão como "total > 100". A idéia é que se a expressão que você colocar for True, o Breakpoint será interrompido.

Uma outra forma de TypeCasting.

Provavelmente você já fez um TypeCasting, como o da linha abaixo:

DataSet ds = (DataSet) dataGridView1.DataSource;

Na forma acima, se o valor que está sendo convertido, no caso o dataGridView1.DataSource, for nulo ou não for um DataSet, será gerado um erro. Você teria que fazer um tratamento antes de efetuar o cast, usando o operador is para verificar se é realmente do tipo esperado:

if (dataGridView1.DataSource != null && dataGridView1.DataSource is DataSet)
{
DataSet ds = (DataSet) dataGridView1.DataSource;
}

Uma outra forma é fazer o cast com o operador as. Com esse operador, se o valor convertido for nulo ou não for do tipo esperado, será retornado nulo. Com isso, o código acima poderia ser escrito assim:

DataSet ds = dataGridView1 as DataSet;
if (ds != null)
...

Além disso, por não usar parenteses, pode deixar a sintaxe um pouco mais limpa, como no exemplo abaixo:

DataTable tbl = ((DataSet) dataGridView1.DataSource).Tables[0];

poderia ser representada com um conjunto de parênteses a menos usando o as :

DataTable tbl = (dataGridView1.DataSource as DataSet).Tables[0];