Abstraindo camadas de conexão de dados e camadas de apresentação em um aplicativo corporativo

Question

Estamos construindo um aplicativo corporativo no qual incorporaremos múltiplas plataformas para interfaces de usuário (ou seja,webapp ASP.net, aplicativo Windows e, algum dia, aplicativos móveis) e várias plataformas para bancos de dados back-end (ou seja,SQL Server, XML, Oracle).Uma necessidade adicional é que esses bancos de dados back-end sejam centralizados e acessados ​​via web ou localizados no computador cliente e ocasionalmente sincronizados com o servidor central.

Alguém pode dar conselhos sobre como podemos abstrair a camada de interface do usuário e a camada de dados para que possamos criar de forma mais simples a adaptabilidade plug-and-play entre as várias UIs e as várias opções de bancos de dados?Por exemplo:em um caso, podemos ter um aplicativo da web rodando em um servidor centralizado via Internet, e podemos ter máquinas remotas executando cópias localizadas por meio de um aplicativo Windows.Em intervalos programados, gostaríamos que todas as máquinas fossem sincronizadas para que todas pudessem ter dados quase em tempo real.

Também precisamos de conselhos sobre como lidar com as diversas cadeias de conexão envolvidas, de modo que a única configuração que precisaria ser alterada em qualquer aplicativo fosse "local" ou "remota", o que determinaria então a cadeia de conexão necessária.

Answer 1

Abstrair a camada de apresentação é um conceito bastante fácil quando você domina a arquitetura de n camadas.Concentre-se apenas em diferenciar "lógica de domínio" de "lógica de aplicativo".A lógica de domínio é comum em suas diferentes plataformas, e a lógica do aplicativo é específica da plataforma.Por exemplo, validação de dados é lógica de domínio (embora seja bom quando você pode fazer isso no front-end, o que torna as coisas mais complexas, mas trabalhe comigo aqui...) e decidir para qual URL redirecionar após alguma ação é a aplicação lógica.Certifique-se de colocar sua lógica de domínio em um nível que possa ser usado por qualquer plataforma e não coloque nenhuma lógica de aplicativo em sua camada de domínio.

A outra metade da sua pergunta parece ser o seu foco maior, mas gostaria de pedir alguns esclarecimentos aqui, pois posso discernir duas questões essenciais diferentes.

1. Espero que você não esteja buscando o "Santo Graal" da independência do banco de dados.Este é sempre um objetivo elevado superado durante a fase de design, que quase sempre, quase sempre, não é necessário.

   Se não é isso que você está procurando, sugiro que você saiba quais objetos são armazenados em qual meio de persistência e evite a complexidade da flexibilidade e apenas codifique seus caminhos verticais da maneira mais direta possível. que possível.O IE não codifica coisas extras em alguma classe de negócios que armazena seus dados no Oracle para permitir que você os coloque no SQL Server "em algum momento no futuro".(Eu voltei à independência do banco de dados, não foi?)

2. A questão de armazenar dados em cache localmente para melhorar o desempenho de determinadas plataformas é específica dessas plataformas e eu sugiro que você analise os Smart Clients e a estrutura/orientação de cache que a equipe de P&P da MS possui.Tenho trabalhado exclusivamente em coisas da web nos últimos dois anos, mas em 06/05 foi muito bom, e eles têm trabalhado muito em suas coisas de Smart Client nesse meio tempo.

Answer 2

Gostaria de usar o modelo de provedor para estabelecer as conexões de banco de dados em seu aplicativo.

Eu começaria examinando os exemplos e detalhes fornecidos no Microsoft Data Application Block, acho que isso o ajudará a chegar lá.