A camada de acesso a dados deve ser rápida, eficiente, e transparente ao desenvolvedor de aplicativos; A camada de acesso a dados do StrataFrame’s foi desenvolvida para funcionar de acordos com estes critérios. Esta chave detém a lógica de acesso a dados de todo o framework. Desde que permaneça sem estado, e seja usada por todos os objetos de negócios como ponte para acessar o dado armazenado. A camada de acesso a dados é provisionada independentemente (SQL Server, Oracle ou OLEDB), e isto and it alavanca muitas características de otimização dos diferentes provedores que garantem uma excelente performance.

A camada de acesso a dados do StrataFrame’s foi desenhada para ser sem estado e altamente ligada. Sem estado permite todos os objetos de negócios a utilizarem uma instância da mesma classe DataAccessLayer mais do que requerem uma implementação específica da camada de acesso a dados para cada objeto de negócios. A camada de acesso a dados está completamente separada da camada de objetos de negócios e performa somente funções especificamente requeridas pala camada de acesso a dados.

Armazenando uma instância da classe DataAccessLayerem cada instância de objeto de negócios, a camada de acesso a dadosse torna completamente transparente ao desenvolvedor da aplicação. O desenvolvedor nunca chama dirematente mas sim indiretamente através de factory e métodos de recuperação de data dados em um objeto de negócios.

Melhorias alcançadas no ADO.NET 2.0 permitiram a camada de acesso a dados se tornar completamente aperfeiçoada, eficiente e otimizadad. Adicionalmente, a camada de acesso a dados tira vantagem do processamento asíncrono, habilitando a confirmar os registros dos dados armazenados em multiplas threads. Fazendo o thread no acesso a dados, a latencia da aplicação é reduzida, particularmente através de uma VPN ou conexão remota.

A classe de camada de acesso a dados contém suporte no núcleo a concorrência e oferece ao desenvolvedor três escolhas:

None	Esta configuração ira burlar toda o controle de concorrência de registros.
Optimistic	Esta técnica segue diretamente a definicção de concorrência otimista. (Veja MSDN para informações adicionais)
Row Version	Este módulo permite um campo específico para versionamento de linhas. Este é o método mais otimizado para suporte a concorrência desde que requer menores números de testes no servidor para determinar se uma colisão pode potencialmente existir. Quando uma linha é salva, a DataAccessLayer automaticamente atualiza a versão da linha.
Time Stamp	Usando um campo time stamp field é similar a uma método de versão de linha. Quando esta opção é usada, a coluna TIMESTAMP é especificadacomo a chave de versão da chaveao invés de uma coluna baseada em integer.

Opções de Notificação de Colisão
Quando uma exceção de concorrência é detectada pelo framework, a DataAccessLayer recupera o registro conflitante do banco de dados e compara a versão do registro do servidor. Se nenhuma informação mal combinada for encontrada, o registro é forçado a ser salvo e o usuário final não será nunca notificado da colisão de dados. Se a informação diferente for achada, então o usuário final é notificado que alguém mais modificou o registro antes e um formulário é apresentado ao usuário que permite a ele corrigir a concorrência antes de salvar novamente os registros.

Esta auto-manipulação de colisões de dados pode ser desabilitada, e existem propriedades que determinam como o desenvolvedor será notificado se a concorrência de exceção acontecer. Por padrão, um evento é inciado automaticamente pelo formulário de objetos de negócios pai(para apresentar ao usuário final com a lista de valores mal combinados), mas uma objeto de negócios pode ser configurado para exibir uma exceção quando a colisão ocorrer.

A classe DataAccessLayer foi sincronizada para prevenir repercursões não necessárias vindas de acessos simultaneospor multiplas threads. Requisição por dados podem ser feitas somente por camadas de negócios em diferentes threads sem requerer ao desenvolvedor explicitamente sincronizar estas requisições. Além disso, eventos iniciados pela camada de acesso a dados são explicitamente iniciados no aplicativo principal para previnir erros cross-thread quando os eventos forem aumentados na interface do usuário.

Stored Procedures
Configurações CRUD são criticas quando completam com êxito e aperfeiçoam inserções, atualizações e apagar performance entre a DataAccessLayer e o banco de dados. Em alguns casos, políticas da empresa força ao desenvolvedor usar store procedures em toda interação CRUD. Nesta situação as opções CRUD não são somente úteis; elas são vitais. Uma store procedure pode ser especificada para cada operação CRUD (INSERT, UPDATE, and DELETE) através de propriedades nos objetos de negócios, que usa estas configurações de volta quando interagindo com a DataAccessLayer.

Recuperação de Auto Primary Key
Quando um novo registro é criado, os valores de chave primárias(s) são automaticamente recuperados e atualizados com a fonte de dados interna do objeto de negócios. Esta característica pode ser ajudatada também com as configurções CRUD.

Conexões com Servidor sem Limites
Algumas vezes um desenvolvdor pode ter mais de uma fonte de dados que será salva vista, atualizada e apagada. Isto é especificamente quando interagindo com dados incompatíveis ou legados. Consequentemente, uma aplicação StrataFrame permite um ilimitado número de conexões possam ser acessadas por um aplicativo simultaneamente. Os strings de conexão separados que são necessários para cada conexão são gerenciados pelo gerenciador de strings de conexão provido pelo StrataFrame.

Suporte a Múltiplos Tipos de Bancos de Dados
Conexões expansíveis sem limite tem a capacidade de conectar a um número sem limite de bancos de dados ao mesmo tempo. Isto inclui diferentes bancos de dados como SQL Server e FoxPro. Esta funcionalidade é significante porque permite aos objetos de negócios se cominicar aos bancos de dados SQL Server e FoxPro, por exemplo, no mesmo formulário, e o desenvolvedor não tem que gerenciar estas conexões. Esta significa a migração de de aplicativos legados, ou a criação de conversões de dados mais aperfeiçoadas.

Declarações de SELECT Personalizados
Diferente de outros frameworks e Mapeadores de O/R, uma declaração de SELECT personalizada ou stored procedure pode ser facilmente executada para recuperação de dados. O desenvolvedor não está limitado a stored procedures e a declarações SELECT pré-geradas usadas pela camada de acesso a dados.

Comandos Parametrizados e Pesquisas com Stored Procedure
Outra opção de recuperação de dados útil é um DbCommand. Esta é a melhor opção de recuperação de dados quando criando pesquisas dinâmicas ou quando a cláusila WHERE será declarada, ja que os DbCommands tem suporte a parâmetros. Um comando DbCommand parametrizado pode também chamar uma store procedure.

Pesquisas Para Bancos de Dados Não Específicos
Existem circustâncias em que o banco de dados pode mudar de um tipo para outro dependendo do processo e ambiente de instalação. A QueryInformation do StrataFrame permite ao desenvolvedor criar provedores independentes de pesquisas que são convertidos a sintaxe apropriada do SQL pela implemnetaão específica do DbDataSourceItem do banco de dados. Esta característica permite uma simples pesquisa a ser escrita e re-utilizada para pesquisar SQL Server, FoxPro, Oracle ou qualquer outro banco de dados sendo usado pela apliação, euquanto houver dados consistentesentre as estruturas de dados.

Suporte Scalar
StrataFrame tem suporte scalar completo, que permite ao desenvolvedor a rapidamente usar um simples pedaço de dados ou para executar uma pesquisa que faça um simples cálculo e retorne uma valor calculado.

Transações Simultâneas sem Limites
StrataFrame leva o suporte completo a transações a um novo nível permitindo um número ilimitado de transações a serem processadas ao mesmo tempo. Objetos de transação são gerenciados pelo framework permitindo uma aproximação "mãos-livres" ao processo de transações. Cada transação pode ser individulamente controlada, e todos os objetos de negócios tem a habilidade de incluir ou excluir da transação. Isto pode ser bem benéfico quando uma grande transação é processada e o desenvolvedor quer salvar dados de outro objeto de negócios em uma transação separada ou a transação inteira.

Acesso Programático Simples
O processamento transacional pode ser controlado através de métodos simples e acessíveis de acesso como chamar TransactionBegin() junto a TransactionEnd() ou TransactionRollBack(). Qualquer erro ou notificação que necessite ser gerenciada será automaticamente apresentada ao desenvolvedor, que deve simplesmente qual ação tomar.

O modo de debug provê uma completa visualização de cada SQL statement executado em um data source, incluindo declarações SELECT, INSERT, UPDATE e DELETE. Cada declaração é escrita a um arquivo de log no formato HTML mostrando a sintaxe SQL, parâmetros, contexto de transação, conexão, e muitos outros pedaços de informação. Esta característica é inestimável quando tentamos rastrear qualquer tipo de erro do processamento de dados que não pode ser facilmente debugado através do Visual Studio.