Hacker News Reader

Comment by tester34 | Hacker News Reader

>Even having to make the decision to go tables first or code first is a burden

>he very sight of dependency injection configuration is cringe.

I'm curious - why?

Coming from a different perspective: Once you've been using Entity Framework for a while (I assume the OP is referring to EF, since there tends to be a 'Use what microsoft ships' culture in the .NET community), is that the APIs available to a "Code First" approach vs. a "Model First" approach are different. If you use Code First and Code Migrations, you don't have access (without getting out of Code First entirely!) to creating Views; and in EF 6 at least, creating indexes was a chore as well. I believe this has been fixed in EF Core; but regardless the mainpoint still stands: The APIs are different and what is natively available is different. At some point doing "Code First", you'll still need to write raw SQL, and that's unexpected if you are planning on doing your work in C# only.

Regarding Dependency Injection: It's very much suited towards enterprise web applications; and its failure mode is trying to get DI to work seamlessly in a non-web application sense (C# is a general language; and .NET supports console, GUI, and web applications) and once you get out of the we application thread-per-request pipeline, you find yourself hitting rough patches.

Op HSCK 12

I believe the smart advice says don’t go code first if you already know what you’re doing with SQL but it’s definitely sad that there’s such a huge barrier between these modes.

As for DI it can definitely be used fruitfully outside of a web application, I suggest the book Dependency Injection: Principles, Practices, and Patterns if you’re curious. It covers examples from ASP.NET Core MVC to console apps to GUI.

I've iterated on the style of my own development over time, and I hadn't really stepped back to look at where I was now for a while. Interestingly enough, I find that I've "worked around" both of the things you mentioned in one way or another.

I use EF, but generally only for migrations, and use Dapper for all the actual access. This avoids a lot of the headache I've had in the past with EF tracking, lazy loading, and foreign keys. I also avoid using views for anything, even at work where I can guarantee with many 9's worth of certainty that I will always be using MSSQL. Part of this is because EF doesn't support it for Code-First, but part of it is also generally trying to be proactive rather than reactive and pre-generate anything I'd be using a view for. Being able to more easily switch providers and move to a different RDBMS is just a "perk" that I'll likely never take advantage of.

I despise the Microsoft DI system. I won't bother going into details, it just doesn't seem to work "right" (that is, the way I want or expect it to). On the other hand, I've used Autofac for years and just seem to "get" it, so I sometimes go to relatively great lengths to use it, even when the Microsoft version would have been a lot easier to get up and running.

EF alone is a great reason to avoid the .NET ecosystem in my experience.

You aren't forced to use it. It's strange that a single library would make you avoid the entire ecosystem, even though it's one of the most advanced ORMs available.

It permeates everything .NET; try finding documentation that doesn’t assume you’re an EF adherent.

Any documentation that doesn't have to do with EF has nothing about EF. You can use whatever data access code you want. There are thousands of examples of Dapper, for example.

"Dependency injection" frameworks look to me like a hack. In a more expressive language, such as F#, one could probably describe what needs to be done symbolically, and then write interpreters that implement the different behaviours required.

Reply on news.ycombinator.com