|
Having been someone who's had to "setup" the db, app, etc. before ORMs were mainstream, you're wildly overestimating how complicated it was. It doesn't actually take very long, you'd maybe save a couple of days or so on a month project, having to write a a CREATE TABLE and then the corresponding class are actually trivial. You make the design decisions when you write the create statement, the class is simply a copy of it. It's just a bit easier, not a lot. I certainly use ORMs now, but it's a convenience rather than a revolution. The truly revolutionary thing for code from that era of C# were lambda expressions. In all honesty, he's an idiot for not updating his skills. If he simply learnt a bit of modern EF and learnt how to use git, he'd run rings around you. I'd note that "proper" source control practice has been around for well over a decade now (SVN was adequate, just not great for distributed teams), so he must be really adverse to change. The unit testing and DI, on the other hand, is all pretty useless noise in a statically typed language like C#, for all MS push it. The only benefit in DI is keeping the same instance of the EF around, and it's pretty hard to actually get that working properly through-out the entire stack when you want to do anything even remotely creative. As for unit testing, never seen the benefit. I took over a project with something like 50% unit test coverage that I never bothered to keep up, in 3 years the existing tests caught 1 bug. All that highlighted to me that it was an utter waste of time and money it was writing all those tests. |
People have been using source code control since then, but the history of computing is of wheel reinvention and not-invented-here, so we are condemned to rediscover things.
Unit testing is useful for business logic, not for individual functions. If you're writing unit tests around whether or not you go outside an array bound, then you're testing the wrong thing. If, on the other hand, you're making sure that someone under 13 can't signup for a service, that's a reasonable unit test.
DI can be useful for running code, allowing you to instrument the code to identify problems. But that's runtime DI, not compile/deployment time.
As a design pattern, it's more an abstraction / reduction of general parameterized polymorphism, usually dragging in an opinionated framework that requires you to follow a set pattern of development and deployment.