Comparison to Dapper-Extensions

[a-priestley]

Hi there,

I'm just wondering if there's much difference in functionality between this library and Dapper-Extensions?
The reason I ask is that this one has fewer stars on Github (possibly it could be newer?) but also is lot more thoroughly documented.
All I am looking for is a dapper-based approach that will allow for a fluent style of performing joins, filters, predicates, etc, that generates the SQL on the fly.
It looks like this is it, and with superior documentation I believe I will give it a try.

Are there any well-known differences I should be aware of?

Thanks!

[MoonStorm]

I'm curious, are joins supported in any way by Dapper-Extensions?

[a-priestley]

You are right. I'm still learning the ropes in software architecture so I think my confusion lay in the notion that I should not couple my domain to mapping implementations, like a lot of tutorials do with EF Core. But then I read the second paragraph of this page and thought "database entities are not domain object huh... that makes a lot of sense!" So thank you very much for that, hahah.

[MoonStorm]

Yup, these entities are used to form the domain entities, which in turn are used in creating the data transfer objects (DTOs) that are exposed for example by the web api controllers. There are mappings going on between all these layers. You might think there's a lot of data duplication going on (and you're right, there is) but the biggest win comes when all these layers can change without inflicting huge ripple effects and all of them can be tested in isolation, mocking the others.

[a-priestley]

Makes a lot of sense. One more question if that's alright..
I understand that an ORM like EF Core functions by bringing down a "DbSet" of entities. That is if I'm not mistaken, the entire table gets selected and instantiated as entities. You can then query the set, make changes, and save it back to the database.
Does FastCrud do this? Or is a more direct approach (commands are executed directly against the DB)? The latter case is how Dapper-Extensions works, at least out-of-the-box.

[MoonStorm]

No, it's not bringing down the entire table. After the LINQ expressions get resolved into a DB query and the filtered records get read from the DB and mapped into entities in that DB context, what EF is going to do next is called "change tracking". Property values and even entire collections of related entities are being added, removed or updated automatically in the DB when that context gets saved. These are all very sweet features that we don't have and never will.

The Dapper world is very close to the metal and, other than the speed, it lacks in many areas compared to EF. For a brand new project, between Dapper (and derivatives like FastCrud, Extensions, etc) and EF (or NHibernate), I encourage people to use the latter, unless there are specific requirements that need to be fulfilled.

[a-priestley]

Thanks very much for your answers!