Que estratégia de acesso a dados para um aplicativo grande

Question

Estou prestes a embarcar em uma reescrita de uma aplicação VB6 em .NET 3.5SP1. O aplicativo VB6 é muito bem escrita e a camada de dados é completamente baseada em procedimentos armazenados. Eu gostaria de ir com algo automatizado como Linq2SQL / Entity Framework / NHibernate / SubSonic. Evidentemente, eu não usei qualquer uma dessas ferramentas em outra coisa senão descartáveis ??projetos.

O problema potencial temo que possa ter com todas estas escolhas é a velocidade. Por exemplo, agora para recuperar uma única linha (ou a lista inteira), eu uso o seguinte sproc:

ALTER PROCEDURE [dbo].[lst_Customers]
 @intID     INT = NULL
,@chvName   VARCHAR(100) = NULL
AS

SELECT   Customer_id, Name
FROM dbo.Customer
WHERE (@intID IS NULL OR @intID = Customer_id)
 AND (@chvName IS NULL OR Name like ('%' + @chvName + '%'))
ORDER BY name

Para recuperar uma única linha na Linq2SQL / Entity Framework / NHibernate / SubSonic, que estas soluções têm de trazer toda a lista para baixo para o cliente e encontrar a linha que eu preciso?

Então, qual é o consenso para a estratégia de acesso a dados para um aplicativo com um domínio de dados de grande porte?

Answer 1

Eu vou jogar o advogado do diabo e recomendo que você pelo menos, considerar furar com os procedimentos armazenados. Estes representam um pedaço de código que você não tem que re-escrever e depurar. Este artigo do nosso Very Own [tm] Joel Spolsky dá um argumento coerente para evitando re-escreve completas.

Dado um projeto 'greenfield' você pode usar o que quiser, e um mapeador O / R pode muito bem ser uma boa escolha. No entanto, você já declarou que o aplicativo VB6 é bem escrito. Se os sprocs são bem escritos, então você obter algum do seu aplicativo gratuitamente e já vem depurado, mais você começa a reciclar o esquema de banco de dados e evitar a maior parte da dor de migração de dados.

Fowler do Patterns of Enterprise Application Architecture deve dar-lhe algumas boas indicações para projetando uma camada de acesso a dados que vai jogar bem com os procedimentos armazenados sem causar problemas de manutenção.

Isto é feito muito comumente em Oracle / Java Apps. Muitos aplicativos legado da Oracle têm grandes corpos de código de procedimento armazenado em PL / SQL - este foi um back arquitetura padrão nos dias de cliente-servidor de Oracle Forms. É prática comum para escrever um wrapper para os sprocs em Java e construir a interface do usuário no topo do invólucro.

Um dos outros cartazes mencionou que Subsonic pode gerar wrappers para as sprocs.

Uma vez tive a oportunidade de fazer um dicionário de dados hack que gerou uma prova-de-conceito invólucro Java / JDBC para PL / SQL sprocs - IIRC levou apenas um ou dois dias. Dado que não é tão difícil de fazer, eu ficaria surpreso ao descobrir que não há um pouco de escolha em coisas que você pode sair da prateleira para fazer isso. Em uma pitada, escrever o seu próprio não é tão duro.

Answer 2

Eu não posso falar sobre Linq-to-SQL, Entity Framework, nem NHibernate, mas estou no amor com SubSonic. Minha experiência com ele tem sido extremamente positiva.

A forma como essas ferramentas funcionam, em geral, é que eles construir consultas parametrizadas para você em código gerenciado, encapsular que o acesso nas aulas, em seguida, expor essas classes para seus aplicativos. Totalmente gerado Dals rock.

Ao usar as consultas parametrizadas, a sua preocupação de que eles poderiam "tem que trazer toda a lista para baixo para o cliente e encontrar a linha que eu preciso" é tratado. Eles apoiam cláusulas where e outro de filtragem para obter apenas a linha (s) que você precisa. Você pode fazer o equivalente a select * from foo, mas você não está preso nesse modo.

Dito isso, SubSonic faz - quando usada fora da caixa para acesso à tabela direta / vista - derrubar linhas inteiras, que pode ser uma desvantagem em alguns cenários. No entanto, o seu acesso através de procedimentos armazenados não é um problema - eu não posso falar para os outros, mas SubSonic prestativamente cria uma classe SPs encapsular todos os seus procs, permitindo que você chamá-los como métodos, e retornando as DataTables adequadas, que você pode, então, analisar manualmente, conforme necessário. Há também formas de inicializar listas das classes DAL de procs, por isso, se o proc retorna um conjunto de dados que corresponde a uma tabela / ver diretamente, você ainda pode ter a sintaxe mais limpa sem processamento manual.

(SubSonic, por sinal, me curou de "procs para tudo." Agora, normalmente, gastar quase nenhum tempo fazendo procs CRUD como eu fiz no passado, e só acabam usando-os para relatórios complicado. Mas o seu milhagem pode, e de fato vai, variar.)

Answer 3

Eu recomendaria usar SubSonic para gerar todo o código para acessar seus procedimentos armazenados existentes, desta forma você reduzir as chances de regressão por causa de uma nova camada de acesso a dados. Quaisquer novos recursos podem ser então acessado através de usar as classes ActiveRecord que são gerados pelo SubSonic. Isto parece-me ser a abordagem mais segura e mais rápida para continuar,

Eu não concordo com a recomendação NHibernate porque não é muito bem adequado para trabalhar com procedimentos armazenados.

Answer 4

Nós tentamos usar estrutura de entidade como um ORM e correu para vários problemas ao tentar usá-lo com o Desenvolvimento Domain Driven. LINQ to SQL também tem algumas limitações e Microsoft vai parar de apoiá-lo na próxima versão, eu acredito.

Answer 5

Se as consultas estão em procedimentos armazenados, há uma boa chance de que eles já foram bem otimizado. E, provavelmente, eles fazem uso liberal de expressões SQL para joins, subqueries, etc.

Duplicar esse tipo de eficiência e expressividade, precisa , com uma camada tipo ORM abstração que eu esperaria ser um desafio -. Especialmente se você não está totalmente familiarizado com as ferramentas

Você sempre pode refatorar as consultas depois que você começa o resto do aplicativo em linha reta. E o mundo dos ORM está mudando rápido o suficiente para que as opções certamente será diferente quando você chegar lá.

Answer 6

SubSonic, mesmo de acordo com Rob Connery, um dos autores, está escrito mais para apoiar o desenvolvimento rápido de aplicações e menos sobre grandes aplicações. Eu diria que ir com NHibernate como você vai encontrar o mais apoio da comunidade como estrutura testada bem como experimentado e verdadeiro. Você pode obter boas informações de www.dimecasts.net sobre a configuração de seu material NHibernate.