Odio davvero trattare prima con DB, è onestamente la rovina della mia esistenza. Come posso convincere il mio manager che, anche se il lavoro per cambiare è molto. Ne varrà la pena.
Odio davvero trattare prima con DB, è onestamente la rovina della mia esistenza. Come posso convincere il mio manager che, anche se il lavoro per cambiare è molto. Ne varrà la pena.
Per prima cosa ho un odio ardente per DB. Non riesco a trovare alcun vantaggio nell'utilizzarlo in un nuovo progetto. Il codice prima è chiaramente superiore, a meno che tu non sia un DBA che lotta con la sintassi del codice (a quel punto mi chiedo cosa stai facendo come sviluppatore di software).
In realtà, sono sempre stato un fan del modello ancora più grande (in cui crei UML, che genera sia il db che le classi per te). Ma hanno rimosso quell'opzione da EF quindi non ha senso portarlo oltre.
Tuttavia, penso che tu abbia torto qui.
I really hate dealing with DB first, it is honestly the bane of my existence.
Mentre è importante per un'azienda non infastidire i suoi dipendenti, ciò non significa che debbano soddisfare i loro capricci.
Per quanto possa sembrare duro, la tua opinione non è tanto importante per l'azienda, a meno che non sia richiesta. In base alla tua domanda, la società ha già deciso di andare con db prima.
In secondo luogo, stai sorvolando un passaggio molto importante: la decisione spetta al tuo manager. Pensare di poterli forzare ad essere d'accordo con te se ti spieghi semplicemente nel modo giusto è non un'aspettativa realistica.
Potrebbero esserci altri fattori in gioco, di cui non si è a conoscenza. Forse l'intera azienda è stata addestrata inizialmente in DB, e sarebbe troppo costoso doverli riqualificare. Forse tutta la documentazione, o gli standard di codifica, sono costruiti da un approccio orientato al database. Forse la maggior parte del lavoro della tua azienda è correlato al DB, e la maggior parte degli sviluppatori sono DBA con responsabilità secondarie.
Qualunque sia la ragione, non puoi decidere cosa fa l'azienda. Se lo facessi, saresti il manager a prendere la decisione.
although the work to switch is a lot. It will be worth it.
Uno degli errori più comuni del programmatore è pensare che le cose sarebbero andate molto meglio se le avessi ricostruite da zero .
Siamo stati tutti lì. Ognuno di noi pensa che ad un certo punto. Ma 9 volte su 10, in realtà non è corretto.
Quando pensi di creare qualcosa da zero, pensi inerentemente a come tu vorresti costruirlo. E questo è parte del motivo per cui ti piace questa idea: devi fare le cose a modo tuo. (A proposito, questo può essere inconscio. Non ti sto accusando di nulla.)
Inoltre, è probabile che sorvegli anche le numerose correzioni apportate alla logica aziendale sin dal suo inizio. Non tutti sono facilmente correggibili, né implementati. La soluzione perfetta che stai immaginando spesso omette qualsiasi difetto raro o apparentemente poco importante.
Ad esempio, ho già scritto semplici parser CSV, perché non potevo essere disturbato a capire come usare una libreria complicata. Per me , è stato un miglioramento per lo sviluppo. Ma non per gli altri:
Caleth colpisce l'unghia in testa nei commenti:
Consider: It may be cheaper to replace you with someone more familiar with DB first, than change the code – Caleth
Se si sostiene al proprio manager che DB non è adatto per la prima volta; mentre la società ha lavorato con DB per la prima volta con successo per un considerevole periodo di tempo, il tuo manager è più incline a concludere che semplicemente non si adatta alla compagnia.
Detto questo , ti suggerisco di parlare con il tuo manager della possibilità di provare prima i dettagli del codice. Fai questo per un nuovo progetto, perché questo non richiede di riscrivere il codice esistente (che è qualcosa che nessuno vuole fare).
Se pensate sinceramente che il codice EF prima sarà migliore per l'azienda, allora la vostra dimostrazione del concetto lo dimostrerà; senza che tu debba parlare con il manager per concordare qualcosa con cui non è d'accordo.
La cosa fondamentale che devi cambiare è la tua aspettativa. Le tue parole non sono ciò che serve per convincere il manager. Il concetto provato dovrebbe. Le tue parole dovrebbero solo metterti un piede nella porta per mostrare il concetto.
Leggi altre domande sui tag management c# entity-framework