Pergunta

Qual abordagem é melhor: 1) para usar um ORM sistema ou 2) DAL manualmente escrever e BLL terceiros código para trabalhar com o banco de dados?

1) Em um de nossos projetos, decidimos utilizar o sistema DevExpress XPO ORM, e atravessei muitos pequenos problemas que perdeu muito do nosso tempo. AMD ainda de vez em quando nos deparamos com problemas e exceções que vêm desta ORM, e não temos a compreensão e controle desta "caixa preta" completa.

2) Em outro projeto, decidimos escrever o DAL e BLL a partir do zero. Embora esse código chato escrita implícita muitas e muitas vezes, mas esta abordagem provou ser mais versátil e flexível: tivéssemos total controle sobre como os dados foi realizada no banco de dados, como foi obtida a partir dele, etc. E todos os erros poderiam ser fixado de forma direta e fácil.

Que abordagem é geralmente melhor ? Talvez o problema é apenas com o ORM que usamos (DevExpress XPO), e talvez outros ORMs são melhores (como NHibernate)?

Vale a pena usando ADO Entiry Framework ?

Eu achei que o DotNetNuke CMS usa seu próprio DAL e BLL código. E sobre outros projetos?

Gostaria de obter informações sobre sua experiência pessoal : qual abordagem você usar em seus projetos, o que é preferível

Obrigado.

Foi útil?

Solução

Talvez um pouco de ambos é o ajuste direito. Você poderia usar um produto como SubSonic. Dessa forma, você pode criar seu banco de dados, gerar o código DAL (removendo tudo o que chato coisas), usar classes parciais para estendê-lo com o seu próprio código, utilizar procedimentos armazenados, se você quiser, e geralmente ficar mais coisas feito.

Isso é o que eu faço. Acho que é o equilíbrio certo entre automação e controle.

Eu também salientar que eu acho que você está no caminho certo por experimentar diferentes abordagens e ver o que funciona melhor para você . Eu acho que é em última análise, a fonte para a sua resposta.

Outras dicas

A minha experiência pessoal foi que ORM é geralmente uma completa perda de tempo.

Primeiro, considere a história por trás disso. Voltar nos anos 60 e início dos anos 70, tivemos esses DBMSes usando os modelos hierárquicos e de rede. Estes foram um pouco de uma dor de utilização, uma vez ao consultar a eles que você teve que lidar com todos os mecanismos de recuperação: seguir os links entre os registros em todo o lugar e lidar com a situação quando as ligações não eram os links que você queria ( por exemplo, estavam apontando na direção errada para a sua consulta particular). Então Codd pensou-se a idéia de um SGBD relacionais: especificar as relações entre as coisas, digamos, em sua consulta apenas o que você quer, e deixar o negócio DBMS com descobrir a mecânica de recuperá-lo. Uma vez que tivemos um par de boas implementações deste, os caras do banco de dados foram muito feliz, todo mundo ligado a ele, e o mundo estava feliz.

Até os caras OO surgiu no mundo dos negócios.

Os caras OO encontrada esta diferença de impedância: os DBMSes usadas na programação de negócios foram relacional, mas internamente os caras OO armazenado coisas com links (referências), e encontrou as coisas por descobrir os detalhes dos links que eles tinham de seguir e seguir eles. Yup: este é essencialmente o modelo hierárquico ou rede DBMS. Então eles colocaram um grande esforço (muitas vezes engenhoso) em camadas que a rede / hierárquica do modelo de volta para bancos de dados relacionais, incidentalmente jogando fora muitas das vantagens dadas a nós por RDBMSes.

O meu conselho é para aprender o modelo relacional, projetar seu sistema em torno dele se é adequado (muito frequentemente é), e usar o poder do seu RDBMS. Você vai evitar a incompatibilidade de impedância, geralmente você vai encontrar as consultas fácil de escrever, e você vai evitar problemas de desempenho (como a sua camada ORM tomada de centenas de consultas para fazer o que deveria estar fazendo em um).

Há uma certa quantidade de "mapeamento" de ser feito quando se trata de processar os resultados de uma consulta, mas isso vai muito facilmente se você pensar sobre isso da maneira certa: o título da relação do resultado mapeia para um classe, e cada tuplo em relação a um objecto. Dependendo do que mais lógica que você precisa, ele pode ou não ser importante definir uma classe real para isso; pode ser fácil o suficiente apenas para trabalho através de uma lista de hashes gerados a partir do resultado. Basta percorrer e processar a lista, fazendo o que você precisa fazer, e está feito.

Recentemente, tomou a decisão de usar o LINQ to SQL em um novo projeto, e eu realmente gosto dele. É leve, de alto desempenho, intuitiva e tem muitos gurus da Microsoft (e outros) que blog sobre isso.

LINQ to SQL funciona criando uma camada de dados de c # objetos do seu banco de dados. DevExpress XPO trabalha na direção oposta, criando tabelas para seus objetos C # empresariais. O Entity Framework é suposto para trabalhar de qualquer maneira. Eu sou um cara de banco de dados, então a idéia de um quadro projetar o banco de dados para mim não faz muito sentido, embora eu possa ver a atratividade do que isso.

O meu Linq para projeto SQL é um projeto de médio porte (centenas, talvez milhares de usuários). Para projetos menores, por vezes, eu só uso SQLCommand e SQLConnection objetos, e falar diretamente com o banco de dados, com bons resultados. SQLDataSource Eu usei também objetos como recipientes para o meu CRUD , mas estes parecem clunky .

Dals fazer mais sentido quanto maior o seu projeto é. Se ele é um aplicativo web, eu sempre usar algum tipo de DAL, porque eles têm built-in proteções contra coisas como ataques de injeção SQL, melhor manipulação de valores nulos, etc.

Eu debatido se de usar o Entity Framework para o meu projeto, desde que a Microsoft diz que este será o seu go-to solução para acesso de dados no futuro. Mas EF sente imaturo para mim, e se você procurar StackOverflow para Entity Framework, você vai encontrar várias pessoas que estão lutando com pequenos problemas, obtusos. Eu suspeito versão 2 será muito melhor.

Eu não sei nada sobre nHibernate, mas há pessoas lá fora que amam ele e não usar qualquer outra coisa.

Você pode tentar usar NHibernate. Uma vez que é open source, não é exatamente uma caixa preta. É muito versátil, e tem muitos pontos de extensibilidade para você ligar o seu próprio funcionalidade adicional ou substituição.

Comentário 1:

NHibernate é uma true ORM, na medida em que permite que você criar um mapeamento entre o modelo de domínio arbitrário (classes) e seu modelo de dados arbitrária (tabelas, vistas, funções e procedimentos). Você diga a ele como você deseja que suas aulas sejam mapeados para tabelas, por exemplo, se essa classe mapeia para duas tabelas associadas ou duas classes mapear para a mesma mesa, se esta propriedade classe mapeia para uma relação muitos-para-muitos relação, etc. NHibernate espera que seu modelo de dados a ser principalmente normalizada, mas não exige que o seu modelo de dados correspondem precisamente ao seu modelo de domínio, nem gera seu modelo de dados.

Comentário 2:

A abordagem do NHibernate é permitir que você escreva qualquer classes que você gosta, e depois disso para dizer NHibernate como mapear essas classes para tabelas. Não há nenhuma classe base especial para herdar, nenhuma classe lista especial se todas as propriedades de um-para-muitos tem que ser, etc. NHibernate pode fazer a sua magia sem eles. Na verdade, suas classes de objetos de negócios não devem ter quaisquer dependências em NHibernate em tudo. Suas classes de objetos de negócios, por si só, não tem absolutamente nenhum código de persistência ou banco de dados em si.

Você provavelmente vai achar que você pode exercer um controle muito fino sobre as estratégias de acesso de dados que usa NHibernate, tanto que NHibernate é provável que seja uma escolha excelente para os seus casos complexos também. No entanto, em qualquer contexto, você é livre para usar NHibernate ou não usá-lo (a favor do código DAL mais personalizado), como você gosta, porque NHibernate não tenta entrar em seu caminho quando você não precisa dele. Então você pode usar uma DAL personalizado ou DevExpress XPO em uma classe BLL (ou método), e você pode usar NHibernate em outro.

Recentemente, participou suficientemente grande projeto interessante. Eu não juntá-lo desde o início e nós tivemos que suportar a arquitetura já implementadas. acesso a dados para todos os objetos foi implementada através de procedimentos armazenados e gerados automaticamente wrapper de métodos em .NET que retornaram objetos DataTable. O processo de desenvolvimento de tal sistema era muito lento e ineficiente. Tivemos de escrever procedimento armazenado enorme em PL / SQL para cada consulta, que pode ser expressa em consulta LINQ simples. Se tivéssemos usado ORM, teríamos implementar projeto várias vezes mais rápido. E eu não vejo nenhuma vantagem de tal arquitetura.

Eu admito, que é apenas particular não projeto muito bem sucedido, mas eu fiz seguinte conclusão: Antes de recusar a usar ORM pensar duas vezes, você realmente precisa de tal flexibilidade e controle sobre banco de dados? Eu acho que na maioria dos casos não vale a pena o tempo perdido e dinheiro.

Como outros explicar, há uma dificuldade fundamental com ORM que o tornam de tal forma que nenhuma solução existente faz um trabalho muito bom de fazer a coisa certa, na maioria das vezes. Este Blog Post: O Vietnam de Ciência da Computação ecos alguns dos meus sentimentos sobre isso.

O sumário executivo é algo ao longo das linhas das hipóteses e otimizações que são incompatíveis entre objeto e modelos relacionais. Embora os primeiros retornos são bons, como os avanços do projeto, as abstrações de curto ORM queda, e a sobrecarga extra de trabalhar em torno dele tende a anular os sucessos.

Eu tenho usado Negrito para Delphi quatro anos. É ótimo, mas não está mais disponível para venda e que carece de alguns recursos como ligação de dados. ECO o sucessor tem tudo isso. Não, eu não estou vendendo ECO-licenças ou algo, mas eu só acho que é uma pena que tão poucas pessoas percebem o MDD (Model Driven Development) pode fazer. Capacidade de resolver problemas mais complexos em menos tempo e menos bugs. Isto é muito difícil de medir, mas eu ouvi algo como 5-10 desenvolvimento mais eficiente. E como eu trabalhar com ele todos os dias eu sei que isso é verdade.

Talvez algum desenvolvedor tradicional que é centrado em torno de dados e dizer SQL:

  1. "Mas o que sobre o desempenho?"
  2. "I pode perder o controle do que SQL é executado!"

Bem ...

  1. Se você deseja carregar 10000 ocorrências de uma mesa o mais rápido possível, pode ser melhor usar procedimentos armazenados, mas a maioria de aplicação, não faça isso. Ambas as consultas simples SQL Negrito e uso ECO para carregar dados. O desempenho é altamente dependente do número de consultas ao banco de dados para carregar uma certa quantidade de dados. Desenvolvedor pode ajudar dizendo esses dados pertencem um ao outro. Carregá-los como effiecent possível.

  2. As consultas reais que é executado pode, naturalmente, ser logado para pegar quaisquer problemas de desempenho. E se você realmente quer usar o seu hiper otimizado SQL consulta isso não é problema, desde que ele não atualizar o banco de dados.

Há muitos sistema ORM para escolher, especialmente se você usar dot.net. Mas honestamente, é muito, muito difícil de fazer um quadro bom ORM. Deve-se concentrado em torno do modelo. Se a mudança de modelo, deve ser uma tarefa fácil para banco de dados de mudança e o código dependente do modelo. Isto torna mais fácil de manter. O custo para fazer pequenas, mas muitas mudanças é muito baixa. Muitos desenvolvedores fazer o erro para o centro em torno da base de dados e adaptar Everthing em torno disso. Na minha opinião esta não é a melhor maneira de trabalho.

Mais deve tentar ECO. Ela é livre para usar um tempo ilimitado, desde o modelo há mais de 12 classes. Você pode fazer muita coisa com 12 classes!

Eu sugiro que você use Código Smith ferramenta para a criação de NetTiers, que é uma boa opção para o desenvolvedor.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top