É melhor para criar classes de modelo ou ficar com classe de utilitário de banco de dados genérico?

votos
5

Temos uma classe de utilitário simples em casa para nossas chamadas de banco de dados (um invólucro de luz em torno ADO.NET), mas estou pensando em criar classes para cada banco de dados / objeto. Seria coisa inteligente a fazer, ou será que só beneficiam se estivéssemos usando a estrutura completa MVC para ASP.NET?

Portanto, temos o seguinte:

SQLWrapper.GetRecordset(connstr-alias, sql-statement, parameters);
SQLWrapper.GetDataset(connstr-alias, sql-statement, parameters);
SQLWrapper.Execute(connstr-alias, sql-statement, parameters);

Pensando em fazer isso:

Person p = Person.get(id);
p.fname = jon;
p.lname = smith;
p.Save();

ou para um novo recorde -

Person p = new Person();
p.fname = Jon;
p.lname = Smith;
p.Save();
p.Delete();

Será que isso é inteligente, ou seria um exagero? Eu posso ver o benefício para reutilização, mudando banco de dados e manutenção / legibilidade.

Publicado 05/08/2008 em 21:10
fonte usuário
Em outras línguas...                            


4 respostas

votos
8

Esta questão é carregado, dados de criação conduzido vs design orientado domínio. Para qualquer aplicação que tem uma boa quantidade de comportamento, em seguida, design orientado domínio devem ser preferidos. Relatórios, ou aplicações de serviços públicos tendem a funcionar melhor (ou são mais rápidos para desenvolver) com os dados de design orientado.

O que você está perguntando é "minha empresa deve fazer uma mudança fundamental na forma como nós projetamos o nosso código". Como um domínio-freak, minha reação é gritar sim . No entanto, pela natureza simples da sua pergunta, eu não tenho certeza que você compreender plenamente o alcance da mudança que você está propondo. Eu acho que você deveria falar mais de sua equipe sobre isso.

Obter um pouco de literatura, como DDD de Evan livro, ou a fundações ebook livre , e então você estará em uma posição melhor para julgar qual direção você deve percorrer.

Respondeu 05/08/2008 em 21:28
fonte usuário

votos
2

A abordagem que você discutir é considerado um bom um por muita gente, inclusive eu! Aprender esta abordagem vai exigir algum esforço, mas não deixe que lhe fora colocada!

O que sobre apenas tentando um pequeno projeto com LINQ to SQL ? Talvez encontrar um projecto de referência agradável no Google Code , e estudar como outros trabalharam com ele.

É uma ferramenta simples, e vai deixar você se familiarizar com algumas das questões que surgem com objetos de mapeamento para bancos de dados.

Então você vai ser capaz de obter uma sensação para ela , e decidir se vale a pena a curva de aprendizagem.

Haverá novos conceitos para compreender e experimentar, coisas como:

  • Unidade de Trabalho : Quando você executa Salvar e excluir etc, um ORM tende a não fazer isso imediatamente, enquanto um conjunto de registros com base vontade DAL. Isso pode ser surpreendente para que você vai precisar para aprender um pouco sobre isso. Leia-se sobre a Unidade de padrão de trabalho para obter uma compreensão do presente.
  • Operações em massa são um problema com OR / M. Um leitor de dados pode eficientemente interagir através de milhares de linhas, mas com um ORM você tem que ter cuidado quando se trabalha com grandes lotes de objetos. Mais uma vez, ler sobre.
  • Associações parece ótimo quando pode fazer coisas como customer.Orders.Count, mas eles também são a causa de muitos problemas. Você precisa encontrar algumas práticas de segurança a seguir ao trabalhar com as associações.

...para nomear alguns.

Para começar, não se preocupe com a herança e outras coisas, basta começar simples e têm entidades simples que mapeiam para tabelas.

Experimente usá-los da mesma forma que você usaria seu DAL existente. Em seguida, começar a experimentar com associações.

Então talvez tente colocar mais comportamento em suas entidades. Se você começar a gostar disso, e acha que precisa de mais recursos, considerar a experimentar um mais ORM rica em recursos como Lightspeed ou NHibernate .

Espero que isto ajude!

Respondeu 03/10/2008 em 11:07
fonte usuário

votos
2

De maneira nenhuma é MVC o único padrão de design para a Web, mas é um útil.

Adotando apenas o 'M' vai pagar dividendos, na minha opinião, mesmo se você não pode / não vai adotar o 'V' ou 'C'.

Respondeu 05/08/2008 em 21:13
fonte usuário

votos
0

Para mim parece que você está tentando fazer o LINQ já pode fazer por você. Se você está preso em um quadro mais velho em que você não pode usar isso, eu poderia sugerir que você use Subconic ( http://subsonicproject.com/ ) em vez de ter que criar manualmente todos estes modelo objetos à mão.

Eu tinha um projeto onde eu estava em uma situação semelhante e mudou para SUBSONIC meio com resultados fantásticos. Mais rápido desenvolvimento e muito mais fácil de ler o código / uso.

Respondeu 26/09/2008 em 15:41
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more