Otimizando interações entre a camada de lógica de negócios COM+ e a camada de apresentação
Normalmente, a latência entre as camadas de um aplicativo distribuído difere muito. As chamadas entre a camada de apresentação e a camada de lógica de negócios geralmente são uma ordem de grandeza mais lenta do que as chamadas entre a camada de negócios e a camada de dados. Como resultado, o estado mantido é mais caro ao chamar para a camada de lógica de negócios.
Os tópicos a seguir discutem maneiras de passar dados entre as camadas de apresentação e lógica de negócios:
- Passando parâmetros
- Opções de passagem de dados
- Usando um padrão de fábrica para passar dados
- Tópicos relacionados
Passar parâmetros
Para que um determinado conjunto de informações seja passado entre a camada de apresentação e a camada de lógica de negócios, você pode ter uma única linha, várias linhas ou uma combinação de uma única linha (como um cabeçalho) e várias linhas de dados de detalhes. A maneira mais eficiente de passar essas informações entre camadas é por meio de uma única chamada de método. Essa única chamada gerenciaria todo o conjunto de informações a ser transmitido. Isso é necessário, a menos que você opte por controlar a transação a partir da camada de apresentação (e tornar todo o tratamento da transação na camada de apresentação idêntico na função). A Microsoft não recomenda a realização de transações a partir da camada de apresentação porque as chamadas entre essa camada e a camada de lógica de negócios geralmente são as mais lentas de todas as chamadas em um aplicativo de várias camadas.
Uma maneira de criar esse método é passar linhas únicas de informações como parâmetros e passar várias linhas como conjuntos de registros ADO. Os conjuntos de registros são o núcleo da metodologia de acesso a dados ADO da Microsoft, e o uso de conjuntos de registros ADO permite que você passe todas as informações relacionadas a uma única transação em uma única etapa.
Opções de passagem de dados
Há outras opções a serem consideradas ao passar dados. Isso inclui o uso de uma lista de parâmetros e conjuntos de registros ADO (conforme discutido acima), apenas conjuntos de registros ADO, cadeias de caracteres codificadas em XML ou matrizes de estruturas. Esta seção discute cada uma dessas opções.
A tabela a seguir mostra áreas em que é necessário tomar cuidado extra ao usar qualquer uma das quatro diferentes possibilidades de passagem de argumentos. Um "X" representa áreas onde os trade-offs precisam ser compreendidos e ponderados em relação às necessidades de cada projeto. Tente não tomar decisões de aprovação de argumentos por componente. Os benefícios de um modelo de programação consistente ao longo de um projeto superam em muito qualquer vantagem de otimização por método ou por componente em todas as circunstâncias, exceto nas mais extremas. As colunas são descritas na lista que segue a tabela.
| Simultaneidade | WAN | Implantação | Complexidade | |
|---|---|---|---|---|
| Entry | Valor | |||
| Conjuntos de registros |
X |
X |
X |
|
| XML |
X |
X |
X |
|
| matrizes |
X |
X |
X |
As quatro colunas definem áreas a serem observadas ao usar essa opção para passar parâmetros.
- A coluna Simultaneidade representa a necessidade de codificar ou fornecer um mecanismo que gerencia condições de bloqueio em operações de atualização. Como os métodos que executam salvamentos podem representar atualizações, problemas de simultaneidade podem surgir. Dois tipos de bloqueio são predominantes: otimista e pessimista. Bloqueios pessimistas impedem que um usuário obtenha dados para atualização, enquanto outro usuário tem o potencial de executar uma atualização. O bloqueio otimista suporta muito mais usuários, negociando contra a probabilidade de que dois usuários estejam atualizando o mesmo documento ao mesmo tempo. O bloqueio otimista exige a verificação para ver se os dados armazenados correspondem aos dados no momento em que uma cópia dos dados foi acessada para modificação. Os conjuntos de registros ADO fornecem suporte automático para bloqueio otimista. Cenários de atualização envolvendo listas de parâmetros de linha única não fornecem suporte suficiente para verificação de simultaneidade. XML sofre desse mesmo problema, em que nenhum reconhecimento de bloqueio está presente em dados XML.
- A coluna WAN representa as condições em que pode haver contenção de transmissão em uma rede de longa distância (WAN). Quando a WAN não tem capacidade suficiente para gerenciar todos os dados que estão sendo movidos a qualquer momento, os usuários do aplicativo enfrentam atrasos no tempo de resposta. Para oferecer suporte à simultaneidade otimista, os conjuntos de registros ADO desconectados passam duas cópias dos dados do servidor para o cliente. A segunda cópia é usada pelo cliente para determinar o menor conjunto de linhas de atualização a ser repassado quando uma alteração estiver sendo confirmada. Embora isso reduza o tráfego da camada de apresentação para os dados, a carga extra da segunda cópia pode ser significativa. O uso de conjuntos de registros como único meio de passar todas as informações, portanto, faz com que o dobro de dados seja passado entre as camadas do que o necessário, exceto quando o conjunto de linhas de atualização está sendo passado de volta para a camada de dados a partir de uma camada de apresentação.
- A coluna Implantação representa problemas associados à passagem de dados quando uma tecnologia especial é necessária no lado do chamador e do componente da rede. Por exemplo, o uso de conjuntos de registros ADO requer que os componentes do ADO estejam presentes no cliente e no servidor. Os analisadores XML também devem estar presentes em ambos os lados, para evitar a necessidade de codificar analisadores em seus aplicativos.
- A coluna Complexidade é indicada para todas as quatro opções e é uma questão de preferência ou experiência anterior de modelo de programação que pode já estar estabelecida em sua organização de desenvolvimento. Algumas pessoas acham que a passagem de parâmetros é complicada e acham que adiciona muita complexidade ao problema de programação. Manter o controle de qual parâmetro você está manipulando e torná-los todos visíveis em uma janela de edição pode criar uma complexidade logística que alguns desenvolvedores consideram não gerenciável.
O método de passagem de parâmetros também pode ter compensações, como as seguintes:
- Os parâmetros podem envolver o gerenciamento de vários argumentos e tipos de argumentos, bem como ter que decidir quando é apropriado tornar um conjunto de registros um parâmetro.
- Os conjuntos de registros ADO podem cortar relações hierárquicas em parâmetros de método para um ou dois argumentos. Isso simplifica drasticamente o modelo de programação e oferece suporte à adição de colunas posteriormente, mas também oculta a hierarquia de informações. Colocar informações em um conjunto de registros ADO e depois extraí-las envolve saber os nomes de cada coluna ou saber a ordem das colunas. Essa situação pode adicionar complexidade para outros componentes ou desenvolvedores de aplicativos no projeto.
- XML é um giro diferente na complicação de hierarquia oculta mencionada acima. O programador precisa entender o uso de um analisador XML para obter acesso às informações e, muitas vezes, deve saber os nomes de cada item no conjunto de dados antes que o conjunto de dados possa ser encontrado.
- Matrizes de estruturas introduzem a necessidade de um entendimento comum das informações que estão sendo passadas tanto por parte do chamador quanto do componente. Essa necessidade de um mapa compartilhado entre dois elementos do sistema pode levar a dificuldades ao lidar com diferentes versões de componentes. Embora a assinatura do método possa não ser alterada, as alterações nas informações esperadas podem tornar os programas de chamada incompatíveis.
Como os problemas de complexidade associados a todos os quatro métodos de passagem de parâmetros são tão semelhantes, é discutível que haja uma oportunidade de simplificação significativa associada a qualquer seleção.
Usando um padrão de fábrica para passar dados
Um ponto importante do design é a facilidade de uso. No momento em que você decidiu usar conjuntos de registros ADO para passar um conjunto estruturado de detalhes de volta para a camada de apresentação, você introduziu um problema de complexidade. Os programadores da camada de apresentação precisam entender a estrutura desses conjuntos de registros. Um problema de maior complexidade pode surgir quando você exige vários detalhes para que um conjunto de dados seja passado em um conjunto de registros. Para simplificar as coisas, você deve considerar a criação de um método de fábrica de conjunto de registros sempre que pretender exigir que os dados sejam passados em conjuntos de registros ADO estruturados.
A fábrica do conjunto de registros deve retornar um conjunto de registros desconectado vazio, mas gravável, para o chamador. Esse conjunto de registros deve ter os campos apropriados (nomes e tipos de dados) já configurados para que o cliente de chamada não precise saber como fabricar o conjunto de registros. Essa abordagem é muitas vezes referida como o padrão de fábrica e é um padrão de solução comum que resolve a necessidade de criar um objeto de uma dada complexidade sem ter que saber as nuances de criá-lo.
Opções de design simples, como escolher o mesmo nome de parâmetro para a mesma parte de dados em todos os métodos em que essas informações são passadas, facilitam a visualização de um método e o conhecimento do que é esperado. Certificar-se de que a ordem em que argumentos semelhantes são passados seja consistente em toda uma família de métodos fornece um ponto de conforto que impõe um modelo consistente.