Atualmente, muitos sites que usam ASP não usam componentes. Hoje, o editor do FOOXIN Technology Channel descreve brevemente os serviços de divisão entre ASP e componentes. Espero que seja útil para você aprender esse conhecimento.
Serviços de divisão de ASP e componentes
O ASP é mais comumente usado para criar arquivos HTML ou XML para uso por clientes nos servidores, por isso discutimos principalmente esse cenário de uso. Isso traz uma pergunta comum: se as páginas ASP estiverem no servidor, elas pertencem a parte da camada de negócios? No mundo dos componentes, a resposta geralmente é não. Embora o ASP seja executado no servidor e possa estar no mesmo espaço do servidor de aplicativos, isso não o torna parte da lógica de negócios.
Com as ferramentas de interface do usuário em crescimento ou, à medida que mais soluções de negócios para negócios são ativadas, ter essa distinção clara pagará uma enorme recompensa.
Dito isto, vejamos alguns dos critérios de divisão de camada de negócios mais importantes e camadas de apresentação:
Código da interface do usuário separado da lógica de negócios. Isso inclui a gravação de código acoplado à interface do usuário, como o uso de um objeto MTS que usa um componente interno do ASP para separá -lo do código lógico de negócios, como se estivesse em uma DLL diferente.
Transações separadas das páginas ASP. A transação ASP é muito boa em alguns casos, mas os componentes e aplicativos de várias camadas mudam isso. Os componentes não devem confiar na camada do cliente para gerenciar suas transações e semântica lógica de negócios.
Coloque o componente representante (componente que usa a solicitação e a resposta) na mesma máquina e/ou processo que o servidor da web. Se um objeto usando o objeto Componente Interno ASP for colocado em uma máquina remota, todas as chamadas para o componente interno ocorrerão em um formulário de retorno de chamada. O servidor COM+ que chama o cliente do IIS é um servidor COM+, que reduz significativamente o desempenho e complica a configuração de segurança. Esses objetos de ajuste podem ser colocados em um aplicativo COM+ marcado como "ativação da biblioteca".
O ASP existe no servidor, portanto, a página ASP deve cumprir as regras de compartilhamento de recursos e ter em mente a escalabilidade. Por favor, veja os detalhes abaixo:
Em uma "sessão", a gerência deve tentar evitar o status específico do usuário.
Mantenha o ASP sem estado e permita pools de recursos sempre que possível.
Método de operação
Ao avaliar se um segmento de código pertence à lógica de negócios ou à camada de apresentação, pergunte-se: "Se eu precisar substituir minha página ASP por um aplicativo de telefone do tipo botão, esse código ainda é útil?" Se a resposta for "sim", você pode tentar dividi -la no código lógica de negócios ou no código auxiliar da interface do usuário.
Se o código não puder ser usado após a alteração do cliente ou se for um ajudante para construir a interface do usuário, o código pertence à camada de serviço de representação. Está na página ASP, ou em um componente que usa os componentes internos do ASP. Não pertence ao componente de objeto de negócios.
Entenda a diferença entre o cliente de mesa e o ASP
O ASP é um cliente especial de componentes, diferentemente dos aplicativos Win32 tradicionais de thread único na área de trabalho. As principais diferenças estão resumidas da seguinte forma.
Gerenciamento de threads: ASP é um cliente com vários threads. Isso significa que pode haver muitas atividades simultâneas correndo juntas, talvez lidando com diferentes páginas ASP ao mesmo tempo. Isso significa que o objeto não pode ser feito para afirmar falsamente que é o único usuário a ocupar exclusivamente o sistema. Fazer isso pode causar reações inesperadas, por exemplo, desenvolver um mau hábito de armazenar objetos em uma sessão ASP ou variáveis de aplicativo.
Ambiente de segurança: ASP é realizado pelo Internet Information Services 5.0 no site, com três níveis de isolamento: baixo, médio e alto. Mesmo esses sites podem ter diferentes configurações de segurança, permitir ou negar acesso anônimo, autenticar clientes e muito mais. Todas essas configurações criam um grande número de esquemas em que diferentes contas de usuário acabam usando seus objetos.
Crescimento facilmente: esse não é um problema técnico, mas um efeito colateral das instalações fornecidas pelos aplicativos da Web.
Tradicionalmente, a adição da base de usuários a aplicativos de desktop requer um planejamento cuidadoso de transferências para números conhecidos de clientes. ASP mudou o processo. Após a corrida, o aplicativo básico visual do ASP pode ser facilmente aberto para uso por todos os funcionários, todos os parceiros de negócios e todos os clientes local ou em todo o mundo.
Pode ser descrito dessa maneira - um e -mail único com um hiperlink pode aumentar a base de usuários dez vezes. Seu aplicativo está pronto para isso? A única maneira de saber é fazer testes de força em seu site para obter o valor esperado do desempenho real.
Como você deve usar objetos Visual Basic no ASP? Crie e cancele seus objetos no escopo da página.
Ou seja, torne o máximo possível da página ASP e depende apenas de variáveis de sessão ou aplicativo em um estado temporário. Não armazene objetos nas variáveis de sessão ou aplicativo. Isso bloqueia o thread ASP em sua sessão, cancela todos os valores esperados para escalabilidade. Ou seja, o número de usuários processados pelo servidor da Web não excederá dezenas de usuários. Se você precisar armazenar conteúdo em uma sessão ou aplicativo, faça -o um dados em vez de um objeto.
Existem muitas outras diretrizes a seguir. Recomendamos que você leia a coluna "servir", escrita por JD Meier no MSDN Voices. Esta coluna inclui uma ampla gama de técnicas, práticas e dicas que ajudam a desenvolver aplicativos ASP escaláveis e confiáveis e componentes.
Não armazene referências em objetos VB em sessão ou aplicativo
Todos os componentes do Visual Basic 6.0 são "threads de unidades", o que significa que todos são executados em unidades STA. Isso significa que, se um objeto for criado em um thread, todas as chamadas para esse objeto devem ser servidas pelo mesmo thread. Muitos threads (de usuários simultâneos do site) usam a mesma instância do objeto STA, causando uma série de atividades que podem se tornar gargalos no aplicativo.
Além disso, o armazenamento de objetos STA criados com o Server.CreateObject no escopo da sessão pode entrar em contato efetivamente no encadeamento de execução para o usuário atual, limitando assim o número máximo de usuários simultâneos do aplicativo ao 20xn padrão (n = número de processadores).
Método de operação
Se você seguir nossas recomendações para tornar os objetos sem estado, não precisará armazenar referências para reutilização do cliente e armazená -las no escopo do aplicativo. Os clientes poderão criar, usar e cancelar seus próprios objetos de forma independente. Isso reduz a necessidade de manter objetos específicos da sessão porque eles não mantêm o estado específico da sessão.
A maneira recomendada é tornar o objeto sem estado, que acessa o banco de dados ou outras áreas de armazenamento (como cookies e LDAP) quando necessário.
Se você precisar usar dados de sessão ou aplicativo, armazene os dados, em vez do objeto que processa os dados, aqui. Você pode criar uma classe que encapsula o processamento do valor desejado.
Aprenda novo conteúdo no IIS 5.0
O Internet Information Server 5.0 adiciona muitos novos recursos. Essas melhorias foram escritas no artigo MSDN do JD MEIER: Use ASP no IIS 5.0 (inglês).
O exposto acima é uma breve descrição dos serviços de divisão entre asp e componentes compartilhados pelo editor do False New Technology Channel. Espero que você tenha mais conhecimento sobre esse aspecto, o que ajudará o desenvolvimento do ASP.