Hacker News Reader

Comment by ianamartin | Hacker News Reader

I disagree. You can and often should decouple from your database by calling only parameterized stored procedures. Your code only needs to know the name of the proc and the paeans to pass.

In non-trivial applications this is where you get the best performance bang for your buck. ORMs are convenient dev tools, but I don’t see them as real options for deploying real apps of any meaningful scale.

View on HN

Plenty of non-trivial applications use ORMs. StackOverflow uses an ORM (Dapper).

There is a world of difference between a Micro-ORM such as Dapper and a bloated mess of an ORM like Entity Framework. They are not even close to the same thing.

Stored Procedures -- oh $diety no. You can't unit test them, they are harder to rollback than code, more difficult to deploy.

You can, and you should. http://tsqlt.org

Being able to write decent unit test suites is one of the biggest things that moved me from inline SQL back toward sprocs.

I don't do inline Sql. I use Linq and Moq out the EFContext with List<T>

https://msdn.microsoft.com/en-us/library/dn314429(v=vs.113)....

It's faster, in memory and multiple people can test simultaneously without contention issues. I've done the whole wrap sql tests in a transaction thing, it was slow and wrought with database locks.

The added advantage is that if you do it right. You not only can switch between different RDMSs you can switch to anything that has a Linq provider. I have a mix of SQL Server and Mongo and the clients don't know the difference they just pass in Expression like (e => e.Id && e.salary > 50000) and it gets translated at runtime to either MongoQuery or Sql. I've switch between the two and they never knew the difference - just update a nuget package.

Reply on news.ycombinator.com