Re:To ORM or Not to ORM
by rawoke083600 on Wednesday May 08, 2019 @01:10AM
(#19856030)
Damn that's a lot of enterprise level words and acronyms to just "store some data". Lol not saying you wrong... just don't like this part of our industry. Is it too late to go back to Turbo Pascal (record-files) ? :)
Not sure I really mentioned much 'enterprise-level', beyond SQL Server?
I guess I'm making it sound more complicated than it really is then, because this approach is actually a lot simpler than the 'N-tier' abstraction-hell of yesteryear.
Jimmy Bogard has a simple example here: https://github.com/jbogard/ContosoUniversityDotNetCore
Some code can probably explain it better than me ;)
Automatic migrations I like less. In particular, Entity Framework and Entity Framework Core migrations.
Firstly, it seems that the second you stray from the most basic of scenarios, thry generate incorrect DDL.
Secondly, I'm just not a fan of 'magic' code gen.
Thirdly, every entity/model change a dev makes does not need to equate to a schema migration - that's how you end up quickly accumulating hundreds of schema migrations.
When I have to use MS SQL Server, the approach I favour is to use CQRS, using EF Core for the majority of cases, then using Dapper when I need more control. And for migrations I like DbUp, because it provides me with full control over when it's time to create a migration file, and what better DSL for migrations than... SQL.