Come convincere i miei colleghi a non utilizzare set di dati per lo sviluppo aziendale (.NET 2.0+)

Question

Tutti quelli con cui lavoro sono ossessionati dall'approccio incentrato sui dati allo sviluppo aziendale e odiano l'idea di utilizzare raccolte/oggetti personalizzati.Qual è il modo migliore per convincerli del contrario?

Answer 1

Se stai lavorando su codice legacy (ad esempio, app trasferite da .NET 1.x a 2.0 o 3.5), sarebbe una cattiva idea partire dai set di dati.Perché cambiare qualcosa che già funziona?

Se, tuttavia, stai creando una nuova app, ci sono alcune cose che puoi citare:

• Appello all'esperienza Dolore nel mantenere le app che si attaccano ai DataSet
• Cita i vantaggi in termini di prestazioni per il tuo nuovo approccio
• Esca loro con una buona via di mezzo.Passa a .NET 3.5 e promuovi LINQ to SQL, ad esempio:pur rimanendo fedele all'architettura basata sui dati, rappresenta un enorme, enorme allontanamento dai set di dati indicizzati in stringhe e impone...Ecco!Collezioni personalizzate: in modo nascosto.

Ciò che è importante è che qualunque approccio utilizzi, rimani coerente e sei completamente onesto con i pro e i contro dei tuoi approcci.

Se tutto il resto fallisce (ad esempio, hai un team di sviluppo che rifiuta assolutamente di abbandonare le vecchie pratiche ed è scettico nell'imparare cose nuove), questo è un segno molto, molto chiaro che sei diventato troppo grande per la tua squadra, è ora di lasciare la tua azienda!

Answer 2

Fatelo con l'esempio e procedete con leggerezza.Qualunque cosa più forte ti allontanerà dal resto della squadra.

Ricorda di considerare la possibilità che abbiano scoperto qualcosa che ti sei perso.Far parte di una squadra significa imparare e insegnare a turno.

Nessuna singola persona ha tutte le risposte.

Answer 3

Ricorda di considerare la possibilità che abbiano scoperto qualcosa che ti sei perso.Far parte di una squadra significa imparare e insegnare a turno.

Distaccato.L’intera idea che lo “sviluppo aziendale” sia in qualche modo distinto dallo sviluppo normale (e di solito l’implicazione è “più importante di”) mi dà davvero fastidio.

Se c'è davvero un vantaggio nell'usare una certa tecnologia, allora dovrai stilare un elenco ponderato di tutti i pro e i contro che si verificherebbero se cambiassi.
Presenta questo elenco ai tuoi colleghi insieme a spiegazioni ed esempi per ciascuno di essi.

Devi essere realistico quando crei questo elenco.Non puoi semplicemente dire "Ci fa risparmiare un sacco di tempo!!!VINCI!!" senza affrontare il fatto che a volte ci vorrà PIÙ tempo, X mesi per essere al passo con la nuova tecnologia, ecc.Devi mostrare esempi concreti in cui si farà risparmiare tempo ed esattamente come.

Allo stesso modo non puoi semplicemente ignorare i contro come se non avessero importanza, i tuoi colleghi Volere chiamarti per questo.
Se non fai queste cose, o se dai l'impressione che spingi semplicemente ciò che ti piace personalmente, nessuno ti prenderà sul serio e ti guadagnerai solo la reputazione di essere il ragazzo pieno di entusiasmo ed energia ma non ne ha idea di nulla.

A proposito.Fai attenzione a questo particolare truffatore.Supererà tutto, a meno che tu non abbia un quantità di casi forti per tutte le tue altre cose:

• Richiede più di 12 mesi di lavoro per trasferire il nostro codice esistente.Hai perso.

Answer 4

Naturalmente "dipende" dalla situazione.A volte DataSet o DataTable sono più adatti, ad esempio se si tratta davvero di una logica aziendale piuttosto leggera, di una gerarchia piatta di entità/record o di alcune funzionalità di controllo delle versioni.

Le raccolte di oggetti personalizzati brillano quando desideri implementare a gerarchia/grafico profondo di oggetti che non possono essere rappresentati in modo efficiente in tabelle 2D piatte.Ciò che puoi dimostrare è un ampio grafico di oggetti e far sì che determinati eventi si propaghino lungo i rami corretti senza invocare oggetti inappropriati in altri rami.In questo modo non è necessario eseguire il ciclo o selezionare ogni singolo DataTable solo per ottenere i record secondari.

Ad esempio, in un progetto in cui sono stato coinvolto due anni e mezzo fa, c'era un modulo dell'interfaccia utente che avrebbe dovuto visualizzare domande e rispondere ai controlli in un singolo WinForms DataGrid (per essere più specifici, era UltraGrid di Infragistics).Alcuni requisiti più complicati

• Il controllo della risposta per una domanda può essere nulla - casella di testo, opzioni della casella di controllo, opzioni dei pulsanti di opzione, elenchi a discesa o anche per visualizzare una finestra di dialogo personalizzata che potrebbe estrarre più dati da un servizio web.
• A seconda della risposta dell'utente, è possibile che vengano visualizzate più domande secondarie direttamente sotto la domanda principale.Se in seguito viene data una risposta diversa, dovrebbe esporre un'altra serie di sotto-domande (se presenti) relative a quella risposta.

L'implementazione originale è stata scritta interamente in DataSet, DataTable e array.La quantità di cicli tra centinaia di righe per più tabelle era semplicemente strabiliante.Non ha aiutato il programmatore che proveniva da un background C++ che tentava di farlo rif tutto (ciao, gli oggetti che vivono nell'heap usano variabili di riferimento, come puntatori!).Nessuno, nemmeno il programmatore originario, potrebbe spiegare perché il codice fa quello che fa.Sono entrato sulla scena più di sei mesi dopo, ed era ancora inondato di insetti.Non c'è da stupirsi che lo sviluppatore di seconda generazione da cui ho preso il posto abbia deciso di smettere.

Dopo aver impiegato due mesi per sistemare il caos caotico, mi sono preso la responsabilità di riprogettare l'intero modulo in un file grafico orientato agli oggetti per risolvere questo problema.sì, completo di classi astratte (per fornire un controllo di risposta diverso su una cella della griglia a seconda del tipo di domanda), delegati ed eventi.Il risultato finale è stato un dataGrid 2D legato a una profonda gerarchia di domande, ordinate naturalmente secondo la disposizione genitore-figlio.Quando la risposta di una domanda del genitore cambiava, veniva generato un evento per le domande dei bambini e questi mostravano/nascondevano automaticamente le loro righe nella griglia in base alla risposta del genitore.Sono stati interessati solo gli oggetti domanda lungo quel percorso.La reattività dell'interfaccia utente di questa soluzione rispetto al vecchio metodo era di ordini di grandezza.

Answer 5

Ironicamente, volevo postare una domanda che fosse esattamente l'opposto di questa.La maggior parte dei programmatori con cui ho lavorato ha adottato l'approccio di oggetti/raccolte di dati personalizzati.Mi si spezza il cuore vedere qualcuno con la definizione della tabella SQL Server aperta su un monitor, digitare lentamente una classe wrapper di riga corrispondente in Visual Studio in un altro monitor (completa di proprietà private e getter-setter per ogni colonna).È particolarmente doloroso se sono anche inclini a creare tabelle da 60 colonne.So che esistono sistemi ORM che possono creare queste classi automaticamente, ma ho visto l'approccio manuale utilizzato molto più frequentemente.

Le scelte ingegneristiche implicano sempre dei compromessi tra i pro e i contro delle opzioni disponibili.L'approccio incentrato sul DataSet ha i suoi vantaggi (rappresentazione in memoria simile a una tabella DB dei dati DB effettivi, classi scritte da persone che sanno cosa stanno facendo, familiari a un vasto pool di sviluppatori ecc.), così come gli oggetti dati personalizzati (controllo del tipo di compilazione, gli utenti non hanno bisogno di imparare SQL ecc.).Se tutti gli altri nella tua azienda seguono il percorso DataSet, è almeno tecnicamente possibile che i DataSet siano la scelta migliore per quello che stanno facendo.

Answer 6

I set di dati/tabelle non sono poi così male, vero?

Il miglior consiglio che posso dare è di usarlo il più possibile nel proprio codice e, si spera, attraverso revisioni tra pari e correzioni di bug, gli altri sviluppatori vedranno come il codice diventa più leggibile.(assicuratevi di spingere il punto quando si verificano questi eventi).

In definitiva, se il codice funziona, il resto è semantica, secondo me.

Answer 7

Immagino che tu possa provare a vendere l'idea della mappatura O/R e degli strumenti di mappatura.Il vantaggio di trattare le righe come oggetti è piuttosto potente.

Answer 8

Penso che dovresti concentrarti sulla performance.Se è possibile creare un'applicazione che mostri la differenza di prestazioni quando si utilizzano DataSet rispetto a entità personalizzate.Inoltre, prova a mostrare loro i principi della progettazione guidata dal dominio e come si adatta ai framework di entità.

Answer 9

Non farne una discussione sulla religione o sulla fede.Quelli sono difficili da vincere (e comunque non è quello che vuoi)

Non inquadrarlo come hai appena fatto nella tua domanda.Il problema non è convincere nessuno a concordare che questo o quel modo sia il modo generale in cui dovrebbero funzionare.Dovresti parlare di come ognuno deve pensare per fare la scelta giusta in un dato momento.fornire un esempio su quando utilizzare dataSet e quando non farlo.

Avevo sviluppatori che utilizzavano dataTable per archiviare i dati recuperati dal database e quindi avevano un codice di logica aziendale che utilizzava quel dataTable...E ho mostrato loro come ho ridotto il tempo per caricare una pagina impiegando 7 secondi con CPU al 100% (sul server web) fino a non riuscire a vedere la linea della CPU muoversi affatto.modificando l'oggetto memoria da dataTable a tabella Hash.

Quindi prendi un esempio o un caso in cui la tua cosa è meglio implementata in modo diverso e vinci quella battaglia.Non combattere una guerra ad alto livello...

Answer 10

Se l'interoperabilità è/sarà una preoccupazione in futuro, DataSet non è sicuramente la direzione giusta da prendere.PUOI esporre DataSet/DataTable su un servizio, ma se DOVREBBE o è discutibile.Se stai parlando di .NET->.NET probabilmente stai bene, altrimenti avrai uno sviluppatore client molto infelice dall'altra parte della barriera che consumerà il tuo servizio

Answer 11

Non puoi convincerli del contrario.Scegli una sfida più piccola o passa a un'altra organizzazione.Se il tuo manager ti rispetta, vedi se puoi realizzare un progetto in stile domain-driven come una sorta di sperimentazione tecnologica.

Answer 12

Se puoi profilare, fallo e basta.I set di dati sono più pesanti di un semplice Collection<T>

I DataReader sono più veloci rispetto all'utilizzo degli adattatori...

Cambiare il comportamento di un oggetto è molto più semplice che modificare un set di dati

Comunque:Fallo e basta, chiedi perdono, non permesso.

Answer 13

Alla maggior parte dei programmatori non piace allontanarsi dalle proprie zone di comfort (si noti che l'intersezione del set "la maggior parte dei programmatori" e il set "Stack Overflow" è probabilmente il set vuoto)."Se prima funzionava (o anche solo funzionava) allora continuate a farlo".Il progetto a cui sto attualmente lavorando ha richiesto molte discussioni per convincere i programmatori più anziani a utilizzare XML/schemi/set di dati anziché solo file CSV (la versione precedente del software utilizzava CSV).Non è perfetto, gli schemi non sono abbastanza robusti per convalidare i dati.Ma è un passo nella giusta direzione.Il codice che sviluppo utilizza astrazioni OO sui set di dati anziché trasferire oggetti del set di dati.In generale, è meglio insegnare con l'esempio, un piccolo passo alla volta.

Answer 14

Ci sono già alcuni ottimi consigli qui, ma avrai comunque molto da fare per convincere i tuoi colleghi se tutto ciò che devi sostenerti sono alcuni commenti di supporto su StackOverflow.E, se sono così scettici come sembrano, avrai bisogno di più munizioni.Innanzitutto, procurati una copia di "Patterns of Enterprise Architecture" di Martin Fowler che contiene un'analisi dettagliata di una varietà di tecniche di accesso ai dati.Leggilo.Allora obbligateli tutti a leggerlo.

Lavoro fatto.

Answer 15

incentrato sui dati significa meno complessità del codice.

oggetti personalizzati significa potenzialmente centinaia di oggetti aggiuntivi da organizzare, mantenere e in generale convivere.Sarà anche un po' più veloce.

Penso che sia davvero una questione tra complessità del codice e prestazioni, a cui è possibile rispondere in base alle esigenze della tua app.

Answer 16

Inizia in piccolo.Esiste un'app di utilità che puoi utilizzare per illustrare il tuo punto?

Ad esempio, nel luogo in cui lavoravo, l'applicazione principale aveva un processo di creazione complicato, che prevedeva la modifica dei file di configurazione, l'installazione di un servizio, ecc.

Quindi ho scritto un'app per automatizzare il processo di creazione.Aveva un'interfaccia utente WinForms rudimentale.Ma poiché ci stavamo spostando verso WPF, l'ho modificato in un'interfaccia utente WPF, mantenendo anche l'interfaccia utente WinForms, grazie a Model-View-Presenter.Per coloro che non avevano familiarità con Model-View-Presenter, era un esempio facilmente comprensibile a cui potevano fare riferimento.

Allo stesso modo, trova qualcosa di piccolo in cui puoi mostrare loro come apparirebbe un'app non DataSet senza dover effettuare un importante investimento nello sviluppo.