Exportar (0) Imprimir
Expandir Tudo
Informações
O tópico solicitado está sendo mostrado abaixo. No entanto, este tópico não está incluído nesta biblioteca.

Navegação inteligente, estrutura de projeto do ASP.NET e muito mais

por Nancy Michell

P: Estou obtendo erros freqüentes no Microsoft Internet Explorer, e eles parecem estar relacionados ao uso do ASP.NET 2.0 com o SmartNavigation ativado. O que o SmartNavigation realmente faz e quando devo usá-lo?

R: SmartNavigation é uma propriedade da classe Page em System.Web.UI. Quando uma solicitação é recebida pelo Internet Explorer 5.5 ou posterior e o SmartNavigation está ativado (definido como true), as seguintes ações são executadas:

  • O flash causado pela navegação é eliminado

  • A posição de rolagem é mantida durante a movimentação entre as páginas

  • O foco no elemento é mantido entre as navegações

  • Apenas o estado da última página no histórico do navegador é retido

No entanto, de acordo com a documentação da Biblioteca de Classes do Microsoft® .NET Framework, a navegação inteligente é usada de forma mais eficiente apenas com páginas ASP.NET que exigem postagens de retorno freqüentes, mas possuem conteúdo visual que não é alterado de forma significativa ao ser retornado.

Na maioria das circunstâncias, essa propriedade não deve ser definida no código. Defina o atributo SmartNavigation como true na diretiva @ Page do arquivo .aspx. Quando a página é solicitada, a classe gerada dinamicamente define essa propriedade para você. A navegação inteligente é um recurso que deve ser testado em seus cenários específicos para garantir que o comportamento apropriado será exibido.

P: Estou tendo alguns problemas com a adoção do ASP.NET 2.0, principalmente porque preciso dividir toda a funcionalidade em compartimentos dentro de um grande aplicativo da Web. Haverá diversos compartimentos de recursos sob o diretório raiz virtual, da seguinte forma:

Internet Bank (virtual directory)
 Accounts (folders)
 ApplicationForms (folders)
 Investments (folders)

Os subdiretórios não podem ser diretórios virtuais, pois todas as áreas precisam compartilhar o estado da sessão, que tem como escopo os diretórios virtuais. Com o ASP.NET 2.0, todos esses arquivos de código estranhos precisam ser colocados em App_Code para serem compilados, dificultando bastante nossa compreensão de quais arquivos em App_Code são usados por quais áreas funcionais. Você pode sugerir uma solução simples para esse problema?

R: O código de code-behind da sua interface do usuário convive com o arquivo .aspx ou .ascx; portanto, ele se relacionará bem com o conteúdo real. É normalmente recomendado o encapsulamento de todo o código de formulário por interface do usuário nesses arquivos (semelhante à forma usada hoje com o Visual Studio® .NET 2003). App_Code é, então, usado para o código compartilhado por todo o aplicativo.

Você poderia organizar o código compartilhado usando subpastas sob o diretório App_Code. Em seguida, poderia usar pastas comuns para organizar seus controles de páginas/usuário em todo o projeto e manter todo o código de code-behind nesse local (o padrão). Consulte a Figura 1 para obter um exemplo.

Caso contrário, em vez de usar o App_Code e ter um único local de armazenamento de todo o código compartilhado, particione o código em três projetos de biblioteca de classes diferentes aos quais o projeto da Web será vinculado. Esses seriam implantados como DLLs no diretório \bin.

P: Estou construindo um serviço da Web em C# que lida com uma tabela de hash global que é acessada por vários usuários simultaneamente. É seguro ter várias pessoas lendo a tabela de hash sem um bloqueio, ao mesmo tempo em que outros segmentos estão gravando dados nela? Precisarei de um bloqueio sempre que eu ler alguma informação da tabela de hash?

R: Se um gravador adicionar um valor que faça com que a estrutura básica da tabela de hash seja redistribuída ou que cause a adição de partições de memória, você terá problemas. Você deverá usar o ReaderWriterLock para garantir a segurança do segmento. Observe também que, se você pretende usar o IEnumerable para enumerar os itens da tabela de hash, uma exceção será gerada caso a tabela de hash seja alterada entre as chamadas a MoveNext.

Para o .NET Framework 2.0, a documentação relacionada a tabelas de hash afirma que é seguro ter vários leitores e um único gravador. A página publicada em Hashtable.Synchronized Method (em inglês) afirma que "Uma System.Collections.Hashtable pode dar suporte a um gravador e a vários leitores simultaneamente".

P: Descobri que quando uso o evento oncontextmenu para criar uma janela pop-up, o pop-up é bloqueado pelo bloqueador de pop-ups do Internet Explorer no Windows XP SP2, mas apenas na zona da Internet. Pelo que eu entendo, pop-ups iniciados pelo usuário não deveriam ser bloqueados. Isso é algo intrínseco ao design? Aqui está o código que estou usando:

<html><body>
<a oncontextmenu="showModalDialog('about:blank'); return false">
    <b>Right</b> click here to invoke a modal dialog.
</a>
<a oncontextmenu="window.open('about:blank'); return false">
    <b>Right</b> click here to invoke a window.open.
</a>
</body></html>

R: WM_CONTEXTMENU não é considerado uma ação iniciada pelo usuário. Você poderia exibir uma divisão flutuante ou usar o window.createPopup, em vez de caixas de diálogo HTML ou window.open. O motivo de isso ocorrer somente na zona da Internet é porque o bloqueador de pop-ups é habilitado por padrão apenas na zona da Internet e em zonas não confiáveis.

As regras para pop-ups determinam que eles não serão bloqueados se forem:

  • Abertos por um link no qual o usuário clicou.

  • Abertos por aplicativos sendo executados no computador. Esses aplicativos incluem adware.

  • Abertos, em ações iniciadas pelo usuário, por controles ActiveX® para os quais um site cria uma instância.

  • Abertos a partir das zonas de Sites Confiáveis ou Intranet Local.

  • Iniciados por um site da lista de permissões de um usuário. (Os usuários podem adicionar sites a suas listas de permissões por meio das configurações do bloqueador de pop-ups.)

  • Iniciados pelo método window.createPopup. Observe que as restrições de janela permitem que apenas uma janela pop-up seja aberta por vez em uma página e que elas limitam a abertura das janelas pop-up iniciadas com esse método à janela do cliente do Internet Explorer.

O usuário é quem determinará se as janelas pop-up deverão ser exibidas em cada um desses casos. Os usuários podem configurar o bloqueador de pop-ups para ser mais ou menos restritivo, ou podem optar por desativá-lo totalmente.

Para obter mais informações, consulte "About the Pop-up Blocker" (em inglês).

P: Existe uma configuração para desabilitar a barra de endereços no Internet Explorer via Diretiva de Grupo? Quais outras configurações do navegador eu posso impor através da diretiva?

R: Sim, você pode desabilitar a barra de endereços e definir inúmeras outras restrições usando a Diretiva de Grupo. As restrições ao navegador disponíveis com o Internet Explorer 6.0 SP1 são mostradas na Figura 2. Instruções para configurar as restrições do navegador podem ser encontradas no artigo da Base de Dados de Conhecimento As restrições que estão disponíveis para o Internet Explorer 6.0 SP1.

P: Estou usando um aplicativo (desenvolvido no Visual Basic) em um ambiente Citrix. Sempre que um link da Web é aberto, ele deve ser aberto na mesma janela do Internet Explorer. Isso funciona bem no ambiente de produção antigo, mas no nosso novo farm do Citrix, uma nova janela do Internet Explorer é aberta todas as vezes. Como posso solucionar esse problema sem tocar no aplicativo em Visual Basic?

R: Leia o artigo 837247 da Base de Dados de Conhecimento, intitulado "A link that has a specified target always opens in a new window if Internet Explorer is the startup program in a Terminal Services session or the shell for the operating system" (em inglês). A solução para o problema envolve baixar e instalar o hotfix em Não é possível acessar as páginas vinculadas da Web de um site acessado através de um atalho para a área de trabalho no Internet Explorer Service Pack 1 e editar o Registro.

P: Eu li que, se você tiver uma página que não altera o estado da sessão, deverá definir o atributo EnableSessionState da diretiva Page como ReadOnly para obter um melhor desempenho. Isso é verdade? E por quê? Como posso conferir esse impacto no desempenho?

R: Considere os dois processos a seguir. Você emite uma solicitação GET para uma página com acesso de leitura/gravação ao estado da sessão. Você extrai o objeto de estado da sessão e faz a desserialização, conforme necessário. Em seguida, processa a página. Depois, você faz o write-back para o objeto de estado da sessão, faz a serialização, conforme necessário, e retorna a resposta ao cliente.

Por outro lado, quando você tem um objeto de sessão somente leitura, você emite uma solicitação GET para a página, obtém o objeto de estado da sessão e o desserializa, conforme necessário. Em seguida, você processa a página e retorna a resposta ao cliente. Portanto, você está poupando as etapas de write-back e também as de resserialização.

Há também um bloqueio criado em um objeto de sessão quando você o acessa como leitura/gravação. Esse bloqueio não é criado com uma sessão somente leitura. Ele é um bloqueio no nível do estado da sessão e é mantido durante todo o tempo de processamento da página e até que seja feito o write-back do estado da sessão para o servidor. Normalmente, esse bloqueio não causa problemas; no entanto, se você usar quadros, verá os problemas começarem a surgir. Quando uma solicitação detecta a impossibilidade de obter um bloqueio exclusivo para o estado da sessão, ela vai para um processo de pesquisa que investiga o bloqueio a cada 500 ms. O bloqueio não é usado quando várias solicitações somente leitura são feitas para o mesmo estado de sessão.

Envie suas dúvidas e seus comentários para webqa@microsoft.com.

Obrigado aos seguintes desenvolvedores da Microsoft por seus conhecimentos técnicos: Mark Atherton, Earl Beaman, Ryan Byington, Todd Carter, Doug Cook, Jeff Davis, Mark Flick, Scott Guthrie, Brett Hill, Keith Homiski, Frank Isernhagen, Darren Jefford, Andreas Klein, Jamie Laflen, Francisco Javier Banos Lemoine, Ajay Mansata, Aditi Maheshwari, Ian Parramore, Gang Peng, Shahar Prish, Ahmad Safa, Mike Skovrinskie, Sean Sutherland, Niall Waller, Brad Wilson e Radomir Zaric.

Da edição de setembro de 2005 da MSDN Magazine Americana.

Mostrar:
© 2015 Microsoft