The use of Object Relational Mapper libraries (ORMs) is so prevalent today that it's uncommon to see anyone question their use.
There are good rea...
For further actions, you may consider blocking this person and/or reporting abuse
Dapper! I love it! I gave EF a try, but just didn't seem to fit my needs. I considered learning EF Core and was advised "if you know Dapper, why bother?". I feel control over my models with Dapper, and as a full stack developer, see my holes in "query" logic immediately. Plus, eliminate the heavy overhead.. always a plus!
I'm sorry but aren't you giving up what ORM is for?
Portability? Do you like replacing all "SELECT TOP X" by "SELECT ... LIMIT X" when porting from MSSQL to MySQL?
What about security and performance (aka SQL injection and SQL plan caching)? Do you write every query as "
DECLARE @param1 int
DECLARE @param2 varchar(20)
DECLARE @param3 datetime
SELECT first,last,login,password,birthdate,street,city,country
FROM Users
WHERE age >= @param1
AND login = @param2
AND created <= @param3"
instead of "
var result = Users.Where(age >= 30 && login = UserLogin && created >= Datetime.Now(-30)).AsList();"
? Don't you feel you're sacrificing something?
Portability is always the first reason that comes up for using an ORM, and I wonder how often switching DB vendors actually happens in the real world.
Also, when using Dapper you really don't need those DECLAREs as it infers them from the values you pass in.
Lastly, your own example shows the cost of the ORM convenience. For instance, say you only need ID and Name for populating a drop-down list, an ORM will select each and every column in the table, whereas in SQL you can SELECT ID, Name.
Nice post which covers a good old-school way if working with date based on ADO.NET.
I thought, that every dev knows what OleDbConnection is responsible for but last time one of my younger didn't know ADO.NET. I'm 31 but I felt old 😉. That why I think posts like this are very handy especially for an inexperienced dev, which has worked only with ORMs.
BTW I like Dapper too, especially for side projects.
I'm waiting for more post about another old-school frameworks.
Cheers.
Thorough. But completely missing anything async-based which is fundamental for scalability in IO scenarios like working with a db.
Thanks. But did you know that in .Net Core all the command methods have an Async conterpart (ExecuteNonQueryAsync, ExecuteReaderAsync, ExecuteScalarAsync)?
Yes... that is exactly what I mean. I feel that given it's availability your article should be demonstrating the
asyncversions, and noting that non-asyncis available if you absolutely need it.I usually try to include the least amount of concepts required to explain/demonstrate an idea, that's why Async isn't there.
You're right.
async,awaitandTask<>really add a ton of code...