Múltiplos Arquivos de Configuração

by Israel Aece 21. August 2005 23:09

Essas configurações geralmente são valores que precisamos para a aplicação, como por exemplo: string de conexão com a base de dados, servidor de SMTP, entre outras. Veremos abaixo como definimos no arquivo Web.Config da aplicação para que o ASP.NET leia as configurações de um outro arquivo:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <appSettings file="Settings.config"/>
    <!-- outras configurações aqui... -->
</configuration>

Como podemos reparar, no atributo file definimos o arquivo chamado "Settings.config" que será o arquivo responsável por armazenar as configurações que nosso projeto utilizará. A estrutura do mesmo é exibida abaixo:

<?xml version="1.0" encoding="utf-8" ?>
<appSettings>
    <add key="TesteKey" value="123456" />
</appSettings>

Feito isso, podemos normalmente utilizar a forma tradicional que fazemos para recuperar e utilizar um valor que está definido no arquivo Web.Config, utilizando a classe ConfigurationSettings. Abaixo é mostrado como recuperar e escrever este valor:

using System.Configuration;

//...

Response.Write(ConfigurationSettings.AppSettings["TesteKey"]);

Tags:

.NET Framework | ASP.NET

Linha do DataGrid - Clicando em qualquer lugar

by Israel Aece 19. August 2005 23:13

Para explicar melhor, analise a figura ao lado. Vemos que temos um botão do tipo Select que marca o registro quando o usuário pressionar. Muitas vezes o usuário quer clicar em qualquer lugar desta linha e executar este processo e não somente em cima daquele controle. Este artigo vai abordar este ponto, ou seja, aprender como gerar esta funcionalidade.



Para que possamos alcançar esse efeito, temos que utilizar o evento ItemDataBound do DataGrid, onde nele deve ser verificado o tipo da linha através da propriedade ItemType para assegurar que é uma linha de registro. Depois desta verificação, recuperamos o controle LinkButton através da coleção de controles que a propriedade Item disponibiliza. De posse do LinkButton, utilizamos o método GetPostBackEventReference da classe Page, onde informamos o controle e é retornado a referência ao código script que é invocado quando o controle é clicado e, consequentemente causa o PostBack. O código abaixo exemplifica o que vimos:

private void DataGrid1_ItemDataBound(Object sender, 
     System.Web.UI.WebControls.DataGridItemEventArgs e){

     if(e.Item.ItemType == ListItemType.AlternatingItem ||
          e.Item.ItemType == ListItemType.Item){

          LinkButton lnk = (LinkButton)e.Item.Cells[0].Controls[0];
          e.Item.Attributes.Add("onClick", Page.GetPostBackEventReference(link, ""));
          e.Item.Attributes.Add("style", "cursor:hand");
     }
}

Como vemos, o retorno do método GetPostBackEventReference adicionamos como value do evento Javascript onClick, que será executado no cliente e terá a mesma função do botão Select. Por último, apenas adicionamos um style na linha do DataGrid para que o cursor do mouse fique em forma de "mão" para dar a impressão ao usuário que a linha é clicável.

Tags:

ASP.NET

Acessando uma URL segura (HTTPS) através de System.Net

by Israel Aece 18. August 2005 23:16

Hoje tive uma experiencia interessante, ou seja, um Windows Service que criei para automatizar alguns processos aqui na empresa utiliza as classes de HttpWebRequest e HttpWebResponse para enviar e recuperar dados de um serviço prestado por terceiros, que corre em cima de HTTPS, depois de migrado para um servidor Windows Server 2003, ao executá-lo e fazer uma requisição a este link seguro, o seguinte erro era retornado:

An unhandled exception of type 'System.Net.WebException' occurred in system.dll
Additional information: The underlying connection was closed: Could not establish trust relationship with remote server.


Fui então fazer alguns testes tentando acessar este mesmo link através do browser, e resultou com sucesso. Pude reparar que ao digitá-lo no browser, uma janela é aberta, perguntando ao usuário se ele quer ou não confiar no certificado digital que é fornecido pelo servidor que estamos tentando acessar. Com certeza optei por sim, e o retorno foi imediato. Mas a questão estava aí, ou seja, se a requisição é feita por um processo automático (Windows Service), que clicaria no botão? :P Nesse caso, criamos uma classe que implementa a interface ICertificatePolicy para gerir e autorizar que o certificado seja aceito. O código para isso é:

     Imports System.Net
     Public Class TrustAllCertificatePolicy

          Implements ICertificatePolicy

          Public Function CheckValidationResult(ByVal srvPoint As System.Net.ServicePoint, ByVal certificate As System.Security.Cryptography.X509Certificates.X509Certificate, ByVal request As System.Net.WebRequest, ByVal certificateProblem As Integer) As Boolean Implements System.Net.ICertificatePolicy.CheckValidationResult
               Return True
          End Function

     End Class


No código acima, através do método CheckValidationResult retornamos True para sempre aceitar e confiar neste certificado. Depois disso, antes de efetuar a requisição devemos definí-la na propriedade CertificatePolicy, como é exibido abaixo:

     System.Net.ServicePointManager.CertificatePolicy = New TrustAllCertificatePolicy

Para conseguir a encontrar essa solução, li o artigo do Jan Tielen, e pode ser visto aqui. Lembrando que isso também é valido para Web Services que rodam em ambiente seguro, como ele explica.

Tags:

.NET Framework | CSD

ASP.NET Development Helper

by Israel Aece 17. August 2005 23:17

Nikhil Kothari disponibilizou em seu blog um Helper para desenvolvimento de aplicações ASP.NET, que é um plugin para o IE, qual tem uma série de recursos, tais como: log de HTTP, Tracer, entre outros.

Tags:

ASP.NET

APIs obsoletas - ASP.NET 2.0

by Israel Aece 15. August 2005 23:18

Com a vinda do novo ASP.NET, o 2.0, muitas coisas que existiam nas versões 1.x acabaram ficando obsoletas, sendo uma delas, a velha conhecida de todos nós, a propriedade SmartNavigation dos WebForms. Ela tem a responsabilidade de manter a posição (scroll) da página quando um PostBack é causado na mesma.

Lendo a listagem de APIs obsoletas do .NET Framework 2.0 Beta 2, vi que a propriedade SmartNavigation foi substituída pela propriedade MaintainScrollPositionOnPostBack da classe Page.

Além disso, a Namespace Mail foi "transportado" para o Namespace System.Net.Mail. Uma outra que sofreu uma grande alteração foram os métodos da classe Page que utilizávamos para trabalhar com código Javascript no cliente (i.e. o método RegisterClientScriptBlock) que agora estão todas dentro de uma classe chamada ClientScriptManager e a classe Page, por sua vez, à expõe através de uma propriedade chamada ClientScript.

Para uma lista completa de todas as APIs obsoletas no .NET Framework 2.0, aconselho a baixar aqui, diretamente da Microsoft e analisar.

Tags: ,

ASP.NET

Analisando o Microsoft PetShop 3.0

by Israel Aece 15. August 2005 15:56

Para quem não conhece, o Microsoft PetShop 3.0 é uma aplicação de uma loja virtual fictícia que vende pequenos animais que a Microsoft construiu com o propósito de um caso de estudo baseado no Java Pet Store da Sun, mas construindo-a sob a Plataforma .NET. Mas este artigo não tem o intuito de mostrar esta comparação e sim abordar a estrutura em que o mesmo foi construído. Para quem se interessar, poderar ver o estudo/análise desta comparação através deste link: http://www.middleware-company.com/buzz/buzz0703.jsp.

Microsoft PetShop 3.0 é uma aplicação Web, construída em ASP.NET, que comunica com componentes de negócios escritos em C#, quais compõem a Camada de Negócios (Business Logic Layer). ADO.NET é utilizado para acessar as Base de Dados, acesso qual está abstraído em uma camada de acesso a dados (Data Access Layer (DAL)), separando-se da camada de negócios.

Figura 1 - Microsoft PetShop 3.0.

Estrutura da Solução

Como podemos ver abaixo na Figura 2, a solução da Aplicação e constituída de diversos projetos, sendo 1 projeto do tipo WebApplication (User Interface), 8 projetos do tipo Class Library e 2 projetos "Build" para efetuar algumas configurações no ato da instalação. Veremos abaixo, a descrição de cada um deles.

Figura 2 - Estrutura da Solução.

 

Projeto Finalidade
BLL Contém as regras do negócio da aplicação.
ConfigTool Utilizado para Encriptar/Descriptar ConnectionString e fazer entradas no Event Log.
DALFactory Classe que determina qual Database será utilizada.
IDAL Interfaces que deverão ser implementadas para cada DAL.
Model Classes de dados ou objetos de negócio.
OracleDAL Implementação específica para acesso a fonte de dados Oracle.
Post-Build Responsável por adicionar os Assemblies no GAC e COM+.
Pre-Build Remove Assemblies do GAC e COM+.
SQLServerDAL Implementação específica para acesso a fonte de dados SQL Server 2000.
Utility Classes utilitárias.
Solution Items StrongKey para assinar os Assemblies.

Aplicação Distribuída

Para que a solução atenda o cenário de uma aplicação distrubuída, são criados duas Base de Dados (MSPetShop e MSPetShopOrders). Em uma delas, são armazenadas as informações referentes aos Produtos, Clientes, Banners, entre outros. Já na segunda Base de Dados, são armazenados os pedidos dos clientes e seus repectivos Items. Veremos abaixo a finalidade de cada uma das tabelas:

Tabela Descrição
Account Informações sobre o Cliente.
BannerData Armazena informações sobre Banners.
Category Categorias dos Produtos.
Inventory Estoque dos Produtos.
Item Detalhes dos Produtos.
LineItem Detalhes dos Items dos Pedidos.
Orders Pedidos realizados por um determinado Cliente.
OrderStatus Status do Pedido.
Product Catalogo dos Produtos.
Profile Perfil do Cliente.
Signon Login dos Usuários.
Supplier Informações dos Fornecedores.

OBS.: As linhas que estão com o fundo cinza, pertencem a Base de Dados "MSPetShopOrders".

Arquitetura

Figura 3 - Arquitetura da Solução.

Como vemos na figura acima, a aplicação está dividida em três grandes camadas: Camada de Apresentação, Camada de Negócios e Camada de Acesso a Dados. O COM+ entra no jogo para garantir a integridade dos pedidos, ou seja, quando efetuamos uma compra, se algo falhar durante a transação, o mesmo será desfeito, mantendo assim a integridade dos dados.

Os componentes de negócios fazem as devidas manipulações para serem exibidas no Front-End, mas tudo começa a ficar interessante a partir daqui.

A idéia é de deixar a aplicação independente de Base de Dados. Isso não seria tão difícil, pois poderíamos utilizar OleDb para acessar qualquer uma das Bases de Dados, criando assim uma única classe genérica de acesso. Mas isso torna a aplicação pouco performática, pois não utiliza os Providers específicos para cada Base de Dados. Um dos requirementos ao construir esta aplicação era justamente obter alta performance, e em virtude disso, é indiscutível o uso dos Providers nativos: SqlClient e OracleClient.

Com essa meta, uma forma de simplicar o acesso aos dados, foi utilizar a Pattern Abstract Factory [Gof], juntamente com Reflection que cria e instancia o objeto correto em runtime. É criado uma Interface genérica, que contém os métodos necessários que deve ser implementada em cada classe de acesso a dados. Para cada classe de acesso a dados, você deve implementar esta Interface, utilizando as classes e o Provider específico para o Banco de Dados que está sendo requisitado.

Depois das classes de acesso a dados de Bases diferentes, cria-se uma Factory, que em runtime, utilizando Reflection, vai identificar qual das classes de acesso a dados irá instanciar, baseando-se em uma chave definida no arquivo Web.Config da aplicação Web. A figura abaixo, ilustra o processo:

Figura 4 - Escolhendo qual DB utilizar.

Se algum dia tivermos a necessidade de que a aplicação atenda a mais um tipo diferente de Base de Dados, por exemplo Microsoft Access, teríamos que seguir o seguinte procedimento:

1 - Criar classes de acesso a dados, utilizando OleDb e nela implementar as Interfaces IDAL;

2 - Compilar estas novas classes e fazer Deploy para o servidor;

3 - Alterar a configuração no arquivo Web.Config para chamá-la.

DAO - Data Access Objects

Data Access Objects ou DAO, é um padrão de projeto que é utilizado para abstrair o acesso a dados da camada de negócios (Business Layer), que por sua vez, acessa a Base de Dados através de Data Access Objects, tornando assim transparente o acesso. A DAO é uma DAL específica para um determinado objeto, fazendo com que a camada de negócios fique sem conhecimento da Base de Dados, pois isto está tudo encapsulado.

Esta abstração encapsula a implementação utilizada para acesso, gravação, gerenciamento da conexão referente a fonte de dados, que realmente não interessa a Business Layer qual o tipo de armazenamento de dados está sendo utilizado.

Figura 5 - Diagrama de Classe da Pattern DAO.

Abstract Factory

Abstract Factory fornece uma Interface ou Classe Abstrata para criar uma família de objetos relacionados dependentes sem especificar a classe concreta. Sendo assim, no projeto PetShop 3.0, é criado uma Interface chamada IDAL, que contém os métodos de manipulação de dados, qual é implementada em todas as classes concretas para accesso à diferentes Base de Dados.

Com isso, ao invés do Cliente instanciar a classe concreta, chama-se método de criação (Factory Method), que invoca a Abstract Factory, e utiliza este objeto para chamar os métodos e/ou propriedades da classe concreta. Ganhamos bastante flexibilidade, pois baseado em uma Key (no caso, chamada de WebDAL) dentro do arquivo Web.Config, em runtime ele saberá qual dos objetos concretos deverá instanciar.

Traduzindo em Código

Para que as coisas fiquem um pouco mais claras, veremos abaixo, como é feito isso. Sabendo que temos que implementar as Interfaces contidas na IDAL, veremos uma delas (Account):

1
2
3
4
5
6
7
 
public interface IAccount
{
    AccountInfo SignIn(string userId, string password);
    AddressInfo GetAddress(string userId);
    void Insert(AccountInfo account);
    void Update(AccountInfo account);
}
 
Código 1 - Interface IAccount.

Na camada de acesso a dados, deve-se implementar esta interface (IAccount) e codificar utilizando o Provider específico para aquela Base de Dados. No caso do PetShop, a implementação foi realizada utilizando o DAAB (Data Access Application Block) que utiliza SqlClient e também implementando para acesso a Base de Dados Oracle, utilizando OracleClient.

1
2
3
4
 
public class Account : IAccount
{
    //...
}
 
Código 2 - Implementado Interface IAccount.

Feito isso, a Factory se encarrega de verificar qual dos objetos instanciar, verificando no Web.Config qual a Base de Dados a ser utilizada, e através de Reflection, carrega a cria a instância da mesma através do Factory Method:

1
2
3
4
5
6
7
8
9
10
 
public class Account
{
    public static PetShop.IDAL.IAccount Create()
    {
        string path = System.Configuration.ConfigurationSettings.AppSettings["WebDAL"];
        string className = path + ".Account";
 
        return (PetShop.IDAL.IAccount) Assembly.Load(path).CreateInstance(className);
    }
}
 
Código 3 - Factory Method.

E finalmente em nossa camada de negócios, utilizamos nossa Factory para que ela gere a instância correta da classe de acesso e manipulação da Base de Dados a ser utilizada no Projeto:

1
2
3
4
5
6
7
8
9
10
11
 
public class Account
{
    public void Update(AccountInfo account)
    {
        if (account.UserId.Trim() == string.Empty)
            return;
        
        IAccount dal = PetShop.DALFactory.Account.Create();
        dal.Update(account);
    }
}
 
Código 4 - "Chamando" o Factory Method na Camada de Negócios.

Conclusão: Como vimos a utilização da Orientação à Objetos no Design de nossas aplicações, nos traz grande produtividade e facilidade em uma posterior manutenção. No caso do PetShop que vimos acima, é um ótimo exemplo, onde precisamos gerar independência de Base de Dados, mas existem vários cenários onde podemos utilizar Abstract Factory e principalmente DAO.

Tags: ,

.NET Framework | ASP.NET

Configurando uma aplicação ASP.NET

by Israel Aece 15. August 2005 15:51

Hoje temos dois arquivos bastante importantes quando trabalhamos com aplicações ASP.NET. São eles: Global.asax e o arquivo Web.Config. Esses arquivos tornam a Aplicação bastante flexível, pois reúnem as configurações e eventos em um único lugar.

Com o arquivo Global.asax, você executa um determinado código quando sua Aplicação é iniciada/finalizada ou até mesmo quando qualquer página da Aplicação for requisitada. Já o arquivo Web.Config, armazena as configurações da Aplicação, tais como: Estado de Sessão, Segurança, Globalização, etc.

Quando se trabalha com o Visual Studio .NET, ao criar uma nova Aplicação do tipo WebApplication, automaticamente ele se encarrega de adicioná-los por padrão è ela.

Figura 1 - Os arquivos Global.asax e Web.Config são criados automaticamente.

O fato de termos várias páginas ASP.NET agrupadas você até pode chamar de Aplicativo, mas isso vai muito além. Um Aplicativo ASP.NET tem além de todas as páginas, handlers de evento, módulos e código executável que é executado dentro de um Diretório Virtual no servidor Web (IIS).

O Diretório \bin

Dentro da raiz do Aplicativo há um diretório chamado "\bin". Dentro dele são armazenados arquivos em formato binário compilados utilizados por seu Aplicativo (um exemplo são os arquivos com extensão *.dll).

Os assemblies colocados aqui estão automaticamente disponíveis para seus arquivos *.aspx, e com isso não precisamos nos preocupar com os procedimentos complexos de criação.

O Arquivo Global.asax

O Diretório Virtual no IIS é grande parte do Aplicativo ASP.NET. Independente da página, o aplicativo é iniciado na primeira vez que ela é solicitada. Enquanto os usuários navegam pelas páginas, o processamento ocorre em segundo plano para tratar do Aplicativo.

O Aplicativo pode cair e ser reiniciado da mesma forma que qualquer Aplicativo tradicional, com a seguinte excessão: enquanto um Aplicativo tradicional é iniciado e executado em um computador desktop permitindo a interação direta com o usuário, um Aplicativo ASP.NET é iniciado e executado em um servidor Web, e o usuário utiliza um browser para acessá-lo.

Lembrando que tudo em .NET Framework é um objeto, temos um objeto chamado HttpApplication, que nos fornece métodos e eventos. Com isso podemos deduzir que sempre que uma página em seu Diretório Virtual for solicitada pela primeira vez, um objeto do tipo HttpApplication é instanciado.

Como as páginas ASP.NET realizamos uma ou mais tarefas individualmente, elas não controlam o Aplicativo de modo geral, não podendo uma página afetar diretamente a outra. Deve existir uma localização central que controla a execução do Aplicativo. Tendo este cenário, entra em cena o arquivo Global.asax.

Conhecido como Arquivo de Aplicação de ASP.NET, o Global.asax permite-nos programar no lugar do objeto HttpApplication e com isso você poderá controlar o seu Aplicativo ASP.NET como faz com qualquer outro objeto por meio de métodos e eventos.

OBS.: Apesar do Visual Studio .NET incluir o arquivo Global.asax por default, ele é totalmente opcional. Se seu Aplicativo não conter um arquivo desse tipo, o programa opera de forma padrão. Desejando adicionar funcionalidades, a sua utilização torna-se essencial.

O arquivo Global.asax é colocado no Diretório raiz do Aplicativo (Exemplo: http://servidor/site/ - c:\inetpub\wwwwroot\site\). O ASP.NET controla o acesso à esse arquivo, de modo que ele não é acessível através do browser, o que garante a segurança. Se alguém tentar executar a URL: "http://www.site.com.br/global.asax" o receberá a seguinte notificação de erro:

Figura 2 - Acessando o arquivo Global.asax através do browser.


Este arquivo é gerenciado pela .NET Framework. Sempre que ele for modificado, o CLR detecta isso e faz com que o Aplicativo seja reiniciado para que as novas mudanças tenham efeito. Isso pode ocasionar transtornos para os usuários finais. Modifique este arquivo somente o necessário.

Programando o arquivo Global.asax

O arquivo Global.asax opera de maneira semelhante as páginas *.aspx. Você utiliza o Global.asax para sincronizar qualquer evento exposto pela classe HttpApplication. Eventos quais veremos abaixo:

Evento Descrição
AcquireRequestState Acionado quando o Aplicativo obtém o cache para a solicitação.
AuthenticateRequest Acionado quando o Aplicativo tenta autenticar a solicitação de HTTP.
AuthorizeRequest Acionado quando o Aplicativo tenta autorizar a solicitação de HTTP.
BeginRequest Acionado quando a solicitação de HTTP é iniciada.
EndRequest Acionado quando a solicitação de HTTP é concluída.
Error Acionado quando surge um erro.
PostRequestHandlerExecute Acionado imediatamente depois do handler de HTTP processar a solicitação.
PreRequestHandlerExecute Acionado imediatamente antes do handler de HTTP processar a solicitação.
PreSenderRequestContent Se a solicitação tiver conteúdo adicional (QueryString, Variáveis de Formulário, etc.), esse evento é acionado imediatamente antes daquele conteúdo ser recebido.
PreSenderRequestHeaders Acionado imediatamente antes de os cabeçalhos de solicitação serem recebidos.
ReleaseRequestState Acionado quando o Aplicativo libera o estado de sessão para a solicitação.
ResolveRequestCache Acionado quando o Aplicativo determina o cache para a solicitação.
UpdateRequestCache Acionado quando o Aplicativo autaliza e libera o cache para a solicitação.

Abaixo o arquivo Global.asax padrão:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 
Imports System.Web
Imports System.Web.SessionState
 
Public Class Global
    Inherits System.Web.HttpApplication
 
    Sub Application_Start(ByVal sender As Object, ByVal e As EventArgs)
        '...
    End Sub
 
    Sub Session_Start(ByVal sender As Object, ByVal e As EventArgs)
        '...
    End Sub
 
    Sub Application_BeginRequest(ByVal sender As Object, ByVal e As EventArgs)
        '...
    End Sub
 
    Sub Application_AuthenticateRequest(ByVal sender As Object, ByVal e As EventArgs)
        '...
    End Sub
 
    Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
        '...
    End Sub
 
    Sub Session_End(ByVal sender As Object, ByVal e As EventArgs)
        '...
    End Sub
 
    Sub Application_End(ByVal sender As Object, ByVal e As EventArgs)
        '...
    End Sub
 
End Class
 
Código 1 - O arquivo Global.asax.

Repare que na Linha 5 herdamos a classe HttpApplication dentro do Global.asax, como expliquei acima.

O arquivo mostrado no Código 1 esta apenas com o Eventos que o próprio Visual Studio .NET deixa criado. Você ainda poderá trabalhar com os Eventos mostrados na tabela acima, e como vemos na Figura 3, logo abaixo:

Figura 3 - Os Eventos do arquivo Global.asax.

Agora veremos abaixo qual a ordem de execução dos Eventos do arquivo Global.asax:

1.  Application_Start
2.  Application_BeginRequest
3.  Application_AuthenticateRequest
4.  Application_AuthorizeRequest
5.  Application_ResolveRequestCache
6.  Session_Start
7.  Application_AcquireRequestState
8.  Application_PreRequestHandlerExecute
9.  Page_Load (arquivo *.aspx) ou qualquer outra saída de página
10. Application_PostRequestHandlerExecute
11. Application_ReleaseRequestState
12. Application_UpdateRequestCache
13. Application_EndRequest
14. Application_PreSendRequestHeaders

OBS.: Vale lembrar que alguns eventos são executados de acordo com alguma circunstância. Um exemplo disso é o caso do Evento Session_Start, que somente é executado quando qualquer página é solicitada por aquele usuário, a partir da segunda vez/página, o Evento não ocorre novamente.

Configurando a Aplicação ASP.NET

Da mesma forma que é importante controlar o processamento do Aplicativo, é necessário configurá-lo. Controle de Acesso, Segurança, Estado de Sessão e até mesmo configurações personalizadas. Para isso o ASP.NET nos fornece um arquivo baseado em texto, que nos dá extensibilidade e fácil configuração.

Além disso, a configuração é hierárquica, ou seja, as informações de configuração de aplicativos são aplicadas de acordo com a estrutura de Diretórios Virtuais do seu site. Os sub-diretórios podem herdar ou anular opções de configuração de seus diretórios-pai.

Por padrão, todos os diretório são herdados de um arquivo de configuração padrão de sistema chamado de machine.config, (localizado em: "WinNT\Microsoft.NET\Framework\Versão\CONFIG).

O arquivo que é responsável pela configuração é o Web.Config, que é um arquivo XML, qual veremos à seguir.

O Arquivo Web.Config

Dentro deste arquivo não há nada de especial, à não ser que ele contém chaves e valores que são reconhecidos pelo ASP.NET. Tais valores são facilmente modificáveis, e como mencionei anteriormente, você pode adicionar suas próprias chaves, para controlar outras operações que o ASP.NET não faz para você.

A estrutura básica de um arquivo Web.Config é essa:

1
2
3
4
5
6
7
8
9
10
11
 
<configuration>
    <configSections>
 
    </configSections>
    <system.web>
 
    </system.web>
    <system.net>
 
    </system.net>
</configuration>
 
Código 2 - Estrutura básica do arquivo Web.Config.

Como vemos, é somente XML. Entre as tags <configuration> há dois elementos diferentes: handlers de seção de configuração e configurações da seção de configurações.

As configurações que configuram seu Aplicativo são pares de chave/valor. Há dois tipos destas seções: system.net e system.web. A primeira seção é para configurar o tempo de execução da .NET em si, portanto, não se preocupe muito com isso. Já a segunda é para controlar o ASP.NET. Suas configurações serão colocadas nas tags <system.web>.

OBS.: O arquivo Web.Config faz distinção entre letras maiúsculas e minúsculas, e sem o formato correto, seu Aplicativo poderá gerar erros.

Abaixo uma tabela com as configurações disponíveis para a utilização no arquivo Web.Config:

Seção Descrição
<appSettings> Utilizada para armazenar suas próprias configurações personalizadas de Aplicativo.
<authentication> Configura como o ASP.NET autentica seus usuários.
<authorization> Configura a autorização de recursos no ASP.NET.
<browsercaps> Responsável por controlar as configurações do componente de capacidades do navegador.
<compilation> Responsável por todas as configurações de compilação.
<customErrors> Indica como exibir erros no navegador.
<globalization> Responsável por configurar as opções de globalização.
<httpHandlers> Responsável pelo mapeamento de URLs de entrada em classes IHttpHandler.
<httpModules> Responsável por configurar Módulos de HTTP dentro de um aplicativo.
<identity> Controla como o ASP.NET acessa seus recursos.
<location> Controla como as configurações se aplicam a um diretório.
<pages> Controla configurações de páginas.
<processModel> Configura as configurações de modelo de processo do ASP.NET em Sistemas de Servidor da Web do IIS.
<sessionState> Configura o Estado de Sessão.
<trace> Configura o Trace (Rastreamento).
<webServices> Controla as configurações dos Serviços da Web.

Como podem ver, o arquivo Web.Config ajuda a tornar a Aplicação bastante flexível, ou seja, podemos definir funcionalidades globais em um único lugar. Além disso, uma das vantagens é que se houver a necessidade de mudar algo dentro do arquivo Web.Config, não há a necessidade de recompilar a Aplicação.

Com tantas tags e atributos, que podem nos deixar confusos, infelizmente o Visual Studio .NET em suas versões 2002 e 2003 não implementou o Intellisense em arquivos *.config. Mas há uma forma de obtermos de terceiros tal funcionalidade no seguinte endereço:

http://www.radsoftware.com.au/web/CodeZone/Articles/IntellisenseWebConfig.aspx

Conclusão: Vimos que o arquivo Global.asax nos permite controlar quase todos os aspectos do processamento de uma página ASP.NET. Você pode utilizar os Eventos do objeto HttpApplication para realizar operações imperceptíveis para o usuário, tornando sua Aplicação muito mais robusta e eficiente. Além disso podemos tornar a nossa Aplicação bastante flexível utilizando o arquivo de configuração Web.Config, fazendo com que a mesma possa reagir rapidamente à qualquer mudança.

Tags: ,

ASP.NET

Formatando valores em colunas do DataGrid

by Israel Aece 15. August 2005 15:46

Frequentemente quando utilizamos um controle do tipo DataGrid, e inserimos valores do tipo Data, Dinheiro, Inteiros ou Decimais, precisamos formatar esse valor de acordo com a finalidade desse Campo. Nesse artigo apresentarei a propriedade DataFormatString da BoundColumn de um DataGrid.

Existem dois tipos de formatação: Standard Formats e Custom Formats. Como o objetivo do artigo é mostrar as formatações mais utilizadas em aplicativos para serem executados nos padrões brasileiros, então deixarei claro o seguinte: O padrão para valores numéricos será adotado o Stardand Format. Já a formatação para datas, será utilizado o Custom Format.

A propriedade DataFormatString fornece uma formatação customizada para o valor inserido na BoundColumn. Esta propriedade consiste em duas partes separadas por dois pontos estando dentro de um par de chaves da seguinte forma: {:}. Isso é válido apenas quando estiver inserindo na BoundColumn valores numéricos ou do tipo data.

A sintaxe é a seguinte: {0:[Formato][Qtde. Casas Decimais]}. O caracter que vem após os dois pontos, é o formato em que o valor será exibido. Você também poderá optar por definir a quantidade de casas decimais da seguinte forma: {0:C2}. A seguir uma lista com os valores possíveis:

Standard Format Descrição
C Exibe o valor no formato de moeda.
D Exibe o valor em formato decimal.
E Exibe o valor no formato cientìfico (exponencial).
F Exibe o valor no formato fixo.
G Exibe o valor no formato geral.
N Exibe o valor no formato numérico.
P Exibe o valor no formato de porcentagem.
X Exibe o valor no formato hexadecimal.

Observações: Os caracteres acima que especificam o formato a ser exibido não são case-sensitive, exceto para o X, pois se ele for minúsculo, os valores serão apresentados em minúsculo, do contrário, serão exibidos em maiúsculo.

Para configurar os valores no DataGrid, clique com o botão direito do mouse em cima do mesmo, e selecione Property Builder. Em seguida, vá até a aba Columns e ao incluir uma nova BoundColumn, a propriedade DataFormatString será habilitada para que você possa definir a formatação customizada. A imagem abaixo ilustra o processo:

Figura 1 - Configurando a propriedade DataFormatString do DataGrid.

A figura abaixo exibe os valores no DataGrid de acordo com a formatação pré-definida na propriedade DataFormatString.

Figura 2 - Configurando a propriedade DataFormatString do DataGrid.

Aqui chamo a atenção para a coluna onde é exibido o valor no formato moeda e o separador de casas decimais. Como não foi definido nenhuma cultura no arquivo Web.Config, por padrão ele adota as configurações regionais definidas no servidor. Se acrescentar a cultura pt-BR nas configurações de nossa aplicação, verão que os valores passarão a serem exibidos no formato brasileiro. Abaixo a ilustrução deixará claro:

1
 
<globalization requestEncoding="utf-8" responseEncoding="utf-8" culture="pt-br" />
 
Código 1 - Alterando a cultura no arquivo Web.Config.

Com essa mudança, agora temos os valores sendo exibidos no padrão brasileiro, conforme mostrado na figura 3:

Figura 3 - Valores sendo exibidos no formato brasileiro.

Além das configurações para valores numéricos, ainda podemos utilizar a propriedade DataFormatString para formatarmos datas que são inseridas no DataGrid. Abaixo uma tabela as as possibilidades de formatação para datas:

Custom Format Descrição
MM/dd/yyyy Formato Mês/Dia/Ano
dd/MM/yyyy Formato Dia/Mês/Ano
hh:mm Formato Hora:Minuto
hh:mm:ss Formato Hora:Minuto:Segundo
dd/MM/yyyy hh:mm:ss Formato Dia/Mês/Ano Hora:Minuto:Segundo

OBSERVAÇÕES: Devemos nos atentarmos para o MM e para o mm, pois maiúsculo significa Mês, já o minúsculo significa Minutos.

Há ainda vários outros padrões para a formatação de datas, quais não optei por colocar aqui por que utilizamos na maioria das vezes o formato brasileiro. Mas para quem se interessar pode encontrar maiores informações no link direto da fonte da Microsoft: Standard DateTime Format Strings.

Como dito anteriormente, a configuração da formatação para data, funciona da mesma forma que a formatação para valores numéricos, ou seja, você define na propriedade DataFormatString da BoundColumn do DataGrid, como por exemplo: {0:dd/MM/yyyy hh:mm:ss}. A Figura 4 ilustra os possíveis formatos para datas:

Figura 4 - Formatando Datas.


IMPORTANTE: Você poderia também ao invés de barras "/" utilizar o hífen "-" como separador para as Datas, ficando a String de formatação da seguinte forma: {0:dd-MM-yyyy hh:mm:ss}.

Poderá também fazer a formatação diretamente no HTML, utilizando a propriedade DataItem em conjunto com a método Format. Exemplo:

1
2
3
 
<asp:TemplateColumn>
    <%# String.Format("{0:c}", Convert.ToInt32(Container.DataItem("NomeDaColuna"))) %>
</asp:TemplateColumn>
 
Código 2 - Formatando valores diretamente no código HTML.

CONCLUSÃO: Com este artigo mostrei as possíveis formas de formatação para valores do tipo numéricos de datas que são inseridos nas BoundColumns do DataGrid. Aconselho a darem uma olhada também no link que coloquei um pouco mais acima que diz respeito à outros tipos de formatação bastante utilizados pelas aplicações.

FormatandoValores.zip (19.08 kb)

Tags:

.NET Framework | ASP.NET | C# | VB.NET

Powered by BlogEngine.NET 1.5.0.0
Theme by Mads Kristensen

Sobre

Meu nome é Israel Aece e sou especialista em tecnologias de desenvolvimento Microsoft, atuando como desenvolvedor de aplicações para o mercado financeiro utilizando a plataforma .NET. [ Mais ]

Twitter

Indicações

Introdução ao ASP.NET Web API - e-Book