Embora muitos sites que usam o ASP não usem componentes, neste artigo, o ASP supõe -se que seja uma ponte entre clientes da Internet e componentes.
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 levanta 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.