Como convencer meus colegas de trabalho a não usar conjuntos de dados para desenvolvimento empresarial (.NET 2.0+)

Question

Todos com quem trabalho são obcecados pela abordagem centrada em dados para o desenvolvimento empresarial e odeiam a ideia de usar coleções/objetos personalizados.Qual é a melhor maneira de convencê-los do contrário?

Answer 1

Se você estiver trabalhando em código legado (por exemplo, aplicativos portados do .NET 1.x para 2.0 ou 3.5), seria uma má ideia afastar-se dos conjuntos de dados.Por que mudar algo que já funciona?

Se você estiver, no entanto, criando novos aplicativos, há algumas coisas que você pode citar:

• Apelo à experiência dor na manutenção de aplicativos que seguem DataSets
• Cite os benefícios de desempenho para sua nova abordagem
• Isque-os com um bom meio-termo.Mude para o .NET 3.5 e promova o LINQ to SQL, por exemplo:embora ainda se apegue à arquitetura orientada a dados, é uma grande mudança para conjuntos de dados indexados por strings e impõe ...voilá!Coleções personalizadas – de uma maneira que fica oculta para eles.

O importante é que, seja qual for a abordagem usada, você permaneça consistente e seja completamente honesto com os prós e os contras de suas abordagens.

Se tudo mais falhar (por exemplo, você tem uma equipe de desenvolvimento que se recusa totalmente a abandonar práticas antigas e é cética em aprender coisas novas), este é um sinal muito, muito claro que você superou sua equipe, é hora de deixar sua empresa!

Answer 2

Faça isso pelo exemplo e pise com leveza.Qualquer coisa mais forte apenas irá aliená-lo do resto da equipe.

Lembre-se de considerar a possibilidade de eles descobrirem algo que você perdeu.Fazer parte de uma equipe significa revezar-se no aprendizado e no ensino.

Nenhuma pessoa tem todas as respostas.

Answer 3

Lembre-se de considerar a possibilidade de eles descobrirem algo que você perdeu.Fazer parte de uma equipe significa revezar-se no aprendizado e no ensino.

Destacado.Toda a ideia de que o “desenvolvimento empresarial” é de alguma forma distinto (e geralmente a implicação é “mais importante que”) do desenvolvimento normal realmente me irrita.

Se realmente houver um benefício em usar alguma tecnologia, você precisará elaborar uma lista ponderada de todos os prós e contras que ocorreriam se você mudasse.
Apresente esta lista aos seus colegas de trabalho junto com explicações e exemplos de cada um.

Você tem que ser realista ao criar esta lista.Você não pode simplesmente dizer “nos poupa muito tempo!!!GANHE!!" sem abordar o fato de que às vezes levará MAIS tempo, exigirá X meses para se familiarizar com a nova tecnologia, etc.Você tem que mostrar exemplos concretos onde economizará tempo e exatamente como.

Da mesma forma, você não pode simplesmente ignorar os contras como se eles não importassem, seus colegas de trabalho vai ligue para você.
Se você não fizer essas coisas, ou parecer que está apenas promovendo o que você gosta pessoalmente, ninguém vai levá-lo a sério, e você apenas ganhará a reputação de ser o cara cheio de entusiasmo e energia, mas não tem ideia. sobre qualquer coisa.

POR FALAR NISSO.Esteja atento a este golpe em particular.Isso superará tudo, a menos que você tenha um muito de casos fortes para todas as suas outras coisas:

• Requer mais de 12 meses de trabalho para portar nosso código existente.Você perdeu.

Answer 4

Claro, “depende” da situação.Às vezes, DataSets ou DataTables são mais adequados, como se realmente fosse uma lógica de negócios bastante leve, uma hierarquia plana de entidades/registros ou apresentando alguns recursos de controle de versão.

Coleções de objetos personalizados brilham quando você deseja implementar um hierarquia/gráfico profundo de objetos que não podem ser representados de forma eficiente em tabelas 2D planas.O que você pode demonstrar é um grande gráfico de objetos e fazer com que certos eventos se propaguem nas ramificações corretas sem invocar objetos inadequados em outras ramificações.Dessa forma, não é necessário fazer um loop ou selecionar cada DataTable apenas para obter os registros filhos.

Por exemplo, em um projeto em que me envolvi há dois anos e meio, havia um módulo de UI que deveria exibir perguntas e responder controles em um único WinForms DataGrid (para ser mais específico, era o UltraGrid da Infragistics).Alguns requisitos mais complicados

• O controle de resposta para uma pergunta pode ser qualquer coisa - caixa de texto, opções de caixa de seleção, opções de botão de opção, listas suspensas ou até mesmo para abrir uma caixa de diálogo personalizada que pode extrair mais dados de um serviço da web.
• Dependendo do que o usuário respondeu, isso pode fazer com que mais subperguntas apareçam diretamente abaixo da pergunta pai.Se uma resposta diferente for dada posteriormente, deverá expor outro conjunto de subquestões (se houver) relacionadas a essa resposta.

A implementação original foi escrita inteiramente em DataSets, DataTables e arrays.A quantidade de looping através de centenas de linhas para múltiplas tabelas foi puramente alucinante.Não ajudou o programador ter experiência em C++ tentando referência tudo (olá, objetos que vivem no heap usam variáveis ​​de referência, como ponteiros!).Ninguém, nem mesmo o programador original, poderia explicar por que o código está fazendo o que faz.Entrei em cena mais de seis meses depois disso e ainda estava inundado de insetos.Não admira que o desenvolvedor de 2ª geração que assumi tenha decidido desistir.

Depois de dois meses tentando consertar a bagunça caótica, decidi redesenhar todo o módulo em um gráfico orientado a objetos para resolver este problema.sim, completo com classes abstratas (para renderizar diferentes controles de resposta em uma célula da grade dependendo do tipo de pergunta), delegados e eventos.O resultado final foi um dataGrid 2D vinculado a uma hierarquia profunda de questões, naturalmente classificadas de acordo com a disposição pai-filho.Quando a resposta de uma pergunta dos pais mudasse, um evento seria gerado para as perguntas dos filhos e eles mostrariam/ocultariam automaticamente suas linhas na grade de acordo com a resposta dos pais.Somente objetos de perguntas nesse caminho foram afetados.A capacidade de resposta da UI desta solução em comparação com o método antigo foi de ordens de magnitude.

Answer 5

Ironicamente, eu queria postar uma pergunta que fosse exatamente o oposto disso.A maioria dos programadores com quem trabalhei optou pela abordagem de objetos/coleções de dados personalizados.Parte meu coração ver alguém com sua definição de tabela do SQL Server aberta em um monitor, digitando lentamente uma classe wrapper de linha correspondente no Visual Studio em outro monitor (completo com propriedades privadas e getters-setters para cada coluna).É especialmente doloroso se eles também tendem a criar tabelas de 60 colunas.Eu sei que existem sistemas ORM que podem construir essas classes automaticamente, mas tenho visto a abordagem manual usada com muito mais frequência.

As escolhas de engenharia sempre envolvem compensações entre os prós e os contras das opções disponíveis.A abordagem centrada no DataSet tem suas vantagens (representação na memória semelhante a uma tabela de banco de dados de dados reais do banco de dados, classes escritas por pessoas que sabem o que estão fazendo, familiares a um grande grupo de desenvolvedores, etc.), assim como objetos de dados personalizados (verificação do tipo de compilação, os usuários não precisam aprender SQL etc.).Se todos os outros na sua empresa estão seguindo o caminho do DataSet, é pelo menos tecnicamente possível que os DataSets sejam a melhor escolha para o que estão fazendo.

Answer 6

Conjuntos de dados/tabelas não são tão ruins, são?

O melhor conselho que posso dar é usá-lo o máximo que puder em seu próprio código e, esperançosamente, por meio de revisões por pares e correções de bugs, os outros desenvolvedores verão como o código se torna mais legível.(certifique-se de insistir quando essas ocorrências acontecerem).

Em última análise, se o código funcionar, o resto é semântica, na minha opinião.

Answer 7

Acho que você pode tentar vender a ideia de mapeamento O/R e ferramentas de mapeamento.O benefício de tratar linhas como objetos é bastante poderoso.

Answer 8

Acho que você deveria se concentrar no desempenho.Se você puder criar um aplicativo que mostre a diferença de desempenho ao usar DataSets versus entidades personalizadas.Além disso, tente mostrar a eles os princípios do Domain Driven Design e como eles se ajustam às estruturas de entidades.

Answer 9

Não faça disso uma discussão sobre religião ou fé.Esses são difíceis de vencer (e não é o que você deseja, de qualquer maneira)

Não enquadre da maneira que você fez na sua pergunta.A questão não é fazer com que ninguém concorde que esta ou aquela forma é a forma geral como deveriam trabalhar.Você deve conversar sobre como cada um precisa pensar para fazer a escolha certa em determinado momento.dê um exemplo de quando usar dataSet e quando não.

Eu tinha desenvolvedores usando dataTables para armazenar dados que buscavam no banco de dados e, em seguida, ter código de lógica de negócios usando esse dataTable...E mostrei a eles como reduzi o tempo de carregamento de uma página, passando de 7 segundos de 100% da CPU (no servidor web) para não conseguir ver a linha da CPU se mover.alterando o objeto de memória de dataTable para tabela Hash.

Portanto, pegue um exemplo ou caso que você acha que é melhor implementado de forma diferente e vença essa batalha.Não lute em uma guerra de alto nível...

Answer 10

Se a interoperabilidade for/será uma preocupação no futuro, o DataSet definitivamente não é a direção certa a seguir.Você PODE expor DataSets/DataTables em um serviço, mas se DEVE ou é discutível.Se você está falando .NET-> .NET provavelmente está bem, caso contrário você terá um desenvolvedor cliente muito insatisfeito do outro lado da cerca consumindo seu serviço

Answer 11

Você não pode convencê-los do contrário.Escolha um desafio menor ou mude para uma organização diferente.Se o seu gerente respeitar você, veja se você pode fazer um projeto no estilo orientado a domínio, como uma espécie de teste de tecnologia.

Answer 12

Se você pode criar um perfil, basta fazer e criar um perfil.Os conjuntos de dados são mais pesados ​​que um simples Collection<T>

DataReaders são mais rápidos que usar adaptadores...

Alterar o comportamento em objetos é muito mais fácil do que massagear um conjunto de dados

De qualquer forma:Apenas faça, peça perdão, não permissão.

Answer 13

A maioria dos programadores não gosta de sair de suas zonas de conforto (observe que a interseção do conjunto 'maioria dos programadores' e do conjunto 'Stack Overflow' é provavelmente o conjunto vazio).“Se funcionou antes (ou apenas funcionou), então continue fazendo”.O projeto em que estou atualmente exigiu muitos argumentos para fazer com que os programadores mais antigos usassem XML/esquemas/conjuntos de dados em vez de apenas arquivos CSV (a versão anterior do software usava CSV).Não é perfeito, os esquemas não são robustos o suficiente para validar os dados.Mas é um passo na direção certa.O código que desenvolvo usa abstrações OO nos conjuntos de dados, em vez de passar objetos de conjunto de dados.Geralmente, é melhor ensinar pelo exemplo, um pequeno passo de cada vez.

Answer 14

Já existem alguns conselhos muito bons aqui, mas você ainda terá um trabalho para convencer seus colegas se tudo o que você tiver para apoiá-lo forem alguns comentários de apoio sobre stackoverflow.E, se eles forem tão céticos quanto parecem, você precisará de mais munição.Primeiro, obtenha uma cópia de "Patterns of Enterprise Architecture" de Martin Fowler, que contém uma análise detalhada de uma variedade de técnicas de acesso a dados.Leia-o.Em seguida, force todos a ler.

Tarefa concluída.

Answer 15

centrado em dados significa menos complexidade de código.

objetos personalizados significam potencialmente centenas de objetos adicionais para organizar, manter e, em geral, conviver.Também será um pouco mais rápido.

Acho que é realmente uma questão de complexidade de código versus desempenho, que pode ser respondida pelas necessidades do seu aplicativo.

Answer 16

Comece pequeno.Existe um aplicativo utilitário que você pode usar para ilustrar seu ponto de vista?

Por exemplo, em um local onde trabalhei, o aplicativo principal tinha um processo de construção complicado, envolvendo alteração de arquivos de configuração, instalação de um serviço, etc.

Então escrevi um aplicativo para automatizar o processo de construção.Ele tinha uma interface de usuário WinForms rudimentar.Mas como estávamos migrando para o WPF, mudei para uma UI WPF, mantendo também a UI do WinForms, graças ao Model-View-Presenter.Para aqueles que não estavam familiarizados com Model-View-Presenter, era um exemplo facilmente compreensível ao qual poderiam se referir.

Da mesma forma, encontre algo pequeno onde você possa mostrar a eles como seria um aplicativo não DataSet sem ter que fazer um grande investimento em desenvolvimento.