On Fri, 16 Sep 2016 at 11:56 Greg Keogh <gfke...@gmail.com> wrote: > The people who think that ORMs are a good idea have a code-centric view of >> the world. >> > > Stored procs! >
I know, right? Finally, someone who shares my enthusiasm! [ ... ] > Databases are unlikely to have a structure that suits coders. > THIS ^^ The goal of writing good quality / low TCO software is not to ensure that things suit a given coder's predilections along the way. > What can bridge the "impedance" gap? Something has to. > I agree. It is called effort. It doesn't matter how much you like stored procs, you still have to get > stuff in and out of them across the gap to the coder's classes. How do > procs help? Are you proposing that more business logic be moved into procs? > It isn't a case of me likely stored procs, it is a case of them a declarative data tier both in terms of its state and also the paths of execution that affect it day to day. The things that change the state of the app become entirely deterministic as opposed to whatever BS EF cooks up. > If so, that way lies madness, as you can't easily integrate proc code into > source control, testing, versioning, builds, etc. > File -> New -> Project -> SQL Server Database Project. Prepare to be amazeballsed. > I've seen whole apps written in T-SQL, and it's quite frightening. > I'm not advocating writing whole apps in T-SQL. Stored procs need to be short and punchy unless you want to spend your life diagnosing deadlocks. David. -- David Connors da...@connors.com | @davidconnors | LinkedIn | +61 417 189 363
