The main advantage here is to get the IDE to write you all the plumbing, i.e. get parameters and return data sorted.
In terms of performance; there is no expression tree for parsing with the stored procedure, so it should be pretty fast. However, internally, we noticed a random slowdown in the LINQ-to-SQL materializer, which can affect you if you use it heavily.
If you need the fastest performance, I recommend looking at the dapper-dot-net that we wrote (and released as OSS) after finding these pause materializers. The use is pretty simple. In particular, it neatly allows you to use dapper to do the hard work, but still use the data types created by the IDE for the data.
Inside we do not use stored procedures; we use a combination of:
- LINQ-to-SQL Expression Tree Code
- LINQ to SQL
ExecuteQuery (etc.) - dapper-dot-net
Performance preference is (in our experience) the last. The first is convenient to write and often fast enough. The middle one is fast, but when the dapper has an almost identical API (and faster), it's hard to love now, p
source share