1) Padrões para desenvolvimento em camadas:

1.2) Tratamentos de erros :

Trabalhando em um sistema em camadas precisamos controlar adequadamente os erros de negócio que possam ocorrer dentro dos componentes. Uma das formas documentadas para fazermos isso é devolvermos status de dentro dos componentes. Mas isso muitas vezes se torna algo não recomendável. Isso porque dá liberdade ao programador da interface de ignorar status de erro ou simplesmente esquecer de trata-lo. Por causa disso a melhor forma de lidar com erros de negócio é disparando um erro personalizado de dentro dos componentes, o que faz com que o client seja obrigado a tratar os erros.

A forma padrão de disparo de erros no .NET é a seguinte :
Throw new Exception("Deu um erro qualquer") Porém isso ainda não é um padrão adequado para erros de negócio.

Isso porque o tratamento seria genérico demais. Veja como seria o tratamento :
Try Catch er as exception End Try

Em um catch como o acima qualquer excessão será capturada, tornando o tratamento genérico e difícil de ser realizado. Para piorar a classe exception não possui um constructor que aceite um código de erro. Consequentemente a identificação de que erro ocorreu teria que ser realizada pelo texto, o que dificulta ainda mais a identificação do erro. Podemos, claro, criar classes de erro personalizadas. Mas se para cada erro de negócio formos criar uma classe de erro personalizada o desenvolvimento se tornará inviável. Então precisaremos criar uma classe de erros de negócio única que possa ser utilizada em toda a aplicação. Para isso precisaremos que esta classe nos permita distinguir entre os diversos erros de negócio que poderão ocorrer, nos deixando utilizar um código para cada erro de negócio. Essa classe ficaria desta forma :

Public Class ErroNegocio Inherits system.Exception Private cod as int64 Public Property CodigoErro() as int64
Get
return(cod)
End Get
Set (value as int64)
cod=value
End Set
End Property Public Sub New(ByVal NumErro as Int64,Byval MSG as String)
Mybase.New(MSG)
CodigoErro=NumErro
End Sub
End Class

Em minha opinião esta metodologia é uma metodologia básica para disparo de erros em sistemas em camadas. Podemos, porém, aperfeiçoar esta metodologia ainda mais. Já trabalhei em um sistema no qual solicitaram que, devido ao tamanho do sistema, as mensagens utilizadas pelo sistema fossem bem documentadas, sendo cadastradas em um banco de dados e recuperadas no momento em que fosse necessário exibi-las. Esse cadastramento gera uma flexibilidade ao sistema, permitindo que todas as mensagens do sistema possam ser facilmente personalizadas. Claro que nem todos os sistemas precisam disso, mas sem dúvida pode ser um recurso interessante para alguns casos. Então vamos planejar o que esta classe deveria conter : - Deve herdar a classe Erro negócio citada anteriormente - O constructor deverá receber apenas o código do erro, pois a mensagem será obtida do banco de dados.

- Precisaremos de uma propriedade para receber a string de conexão. Deverá ser uma propriedade Shared, pois assim será possível configurar a string de conexão uma única vez durante o uso do sistema.

- Precisaremos de um atributo privado que deverá guardar a mensagem que será recuperada do banco.
- Teremos alguma dificuldade com o constructor e a mensagem. O constructor precisa chamar o new da classe base em sua primeira linha. E esse new precisa receber uma mensagem. A solução para isso é transmitir uma mensagem qualquer, "xxx". Mas podemos fazer o override da propriedade Message e devolver através dela o atributo privado que contém a mensagem de banco. Com isso temos uma metodologia que pode ser considerada padrão na geração de erros de negócio no ambiente .NET.

1.3) Criação de componentes de negócio :

Quando criamos um sistema em camadas desejamos reutilizar a camada de negócios para diversos clients, tal como client Web e client Windows Forms.

O client Web, porém, possui características personalizadas. Por exemplo, os componentes de validação. Os componentes de validação geram um padrão para a exibição de mensagens de erro para o usuário do site. É interessante mantermos esse padrão mesmo quando trabalhamos em camadas, com componentes de negócio. Quando utilizamos componentes de negócio as validações encontram-se dentro do componente. Então a forma que temos para integrar as mensagens destas validações é através do uso do Custom Validator, pois o custom validator pode disparar o componente no servidor, realizando a validação. Porém se os dados forem válidos o fato de estarmos disparando o método do custom validator pode fazer com que a operação em questão já seja executada, o que nem sempre é interessante. Para solucionarmos isso pode ser interessante mantermos um padrão na codificação de nossos métodos :

Se temos um método para fazer a tarefa x, podemos dividi-lo em 2 : ValidarX e FazerX.
Com essa divisão as aplicações ASP.NET podem disparar o ValidarX através de um custom validator, com o objetivo de validar a realização da tarefa X e
depois, através do evento click de um botão disparar o FazerX. Aplicações Windows Forms, porém, não precisam desta separação. Então aplicações Windows Forms podem fazer uso de um WebService que agregue as duas chamadas de método em sequencia. Lembrando ainda que a chamada de
WebServices através de Windows Forms favorece a criação de SmartClients.

Assim sendo está divisão dos métodos é um padrão possível para a criação de camadas de negócio que sejam reutilizáveis entre ambiente web e windows e se adaptem a cada um dos dois ambientes. Assuntos não técnicos Precisamos de um voluntário para estudar as design patterns no .NET, cujo documento foi disponibilizado no site BufaloInfo, e realizar uma apresentação sobre esse assunto para todos em nossa próxima reunião.

2) Assuntos não técnicos:

• Nosso site começará a entrar no ar na 2a feira com conteúdo textual. Mas é interessante criarmos algumas aplicações em ASP.NET para nosso site - Gerenciamento de FAQ onde possamos cadastrar as perguntas e respostas mais comuns em nosso grupo
• Gerenciamento de atas de reunião, onde possamos cadastrar atas de nossas reuniões, como essa.
• Que a próxima reunião seja realizada em horário noturno