Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
Never found it an issue with embedded sql, you tend to organise the repositories so they make sense. 80% of your work is simple update/insert/delete/fetch and you can use contrib so this basic sql is done for you.
It's one of those if you can write decent sql and can organise a piss up in brewery you can successfully use Dapper or most other micro-orms.
Dapper does have it's limitations, same for repository pattern but this crap about magic strings is nonsense.
What I mean really is that with the Linq 2 Db approach, the complier checks your Linq, with embedded SQL + parameters it is easy to make mistakes and if you change the DB to a different vendor then the SQL might need to change.
I'm not slating Dapper, I've used it and I like it, was just pointing out to +/- points to consider.
What I mean really is that with the Linq 2 Db approach, the complier checks your Linq, with embedded SQL + parameters it is easy to make mistakes and if you change the DB to a different vendor then the SQL might need to change.
I'm not slating Dapper, I've used it and I like it, was just pointing out to +/- points to consider.
No, fair enough and didnt mean to be defensive though on re-reading my reply i was quite harsh, apologies.
Comment