Source
r/csharp•
FirstVape

Anyone here use Dapper? Would there happen to be ~one place a person new to it could go to learn about the "best of breed" extensions?

I'm just starting to look into Dapper, what I really like from what I've seen so far is the simplicity compared to your typical fully featured ORM. However, while reading articles I constantly come across mention of various different Dapper extensions, in fact I even happened upon this list:

http://nugetmusthaves.com/Tag/Dapper

I have no idea how authoritative that list is, so what I'm hoping someone could help me with, is there some semi-authoritative place where one could find a trustworthy list of Dapper extensions that are most popular and worth investigating? Or, if you'd even like to share the extensions you prefer, that would be appreciated as well.

Posted Jun 2, 2015, 10:53 PM UTC

614
xampl9•

Love Dapper. The only extension I use is Dapper Contrib.

4
FirstVapeOP•

Ideally I'd like to stick to extensions that are pretty mainstream and will be around a year or two or now. I don't need to do anything terribly fancy, but I'd like the basics including insert/update/delete, and would also like to be able if its possible to do things like:

  • select a filtered list of orders, and navigate the interrelated objects (for each order, access order.Customer.Address)
  • select a list of customers and navigate their orders (select list of customers, for each customer, for each order, access order items)

And then perform deletions, updates, etc etc on those.

Do you know if Dapper + Dapper Contrib supports that sort of scenario?

1
xampl9•

Dapper.Contrib only rounds out the CRUD operations to base Dapper. Base Dapper does SELECTs and Contrib adds INSERT, UPDATE, and DELETE functionality. Which, TBH, you could have done in base Dapper anyway, but it's much easier with the additions.

So ... navigating related objects ... Dapper isn't good at that and was never intended to be used for that. You'd want something like a full ORM for something like that.

I will point out however, that a lot of what you're asking for can be done in SQL with joins. Change your data entity object to include that related info as properties, then use Dapper with it's Query functionality, or call a stored procedure to give you the data in the columns that match your data entity. So instead of separate Customer and Address objects, have a CustomerAddress object.

I would think this is the preferred way to do this, as you're utilizing the strengths of each platform - SQL and the database engine to do filtering and joining on some criteria, and Dapper to eliminate the tedious column-to-object mapping.

1
FirstVapeOP•

I think base Dapper can do interrelations: http://www.tritac.com/bp-24-dapper-net-by-example

1
xampl9•

They're doing it via a join in SQL, but they do seem to have the ability to map keys. So ... sort of?? Good enough for a lot of cases, looks like.

1
sidmos8580•

Would you recommend contrib over dapper extensions?

I'm new to the tech and so far I'm thinking I will only use it for select queries but that may change down the road...

1
xampl9•

They both do similar things - try each of them out and go with the one that feels more natural for your coding style.

1
bhrgunatha•

Sorry for the very late response.

How do you go about managing the actual SQL statements for a project? Do you hard code them in place. Are you lucky enough to have simple POCO <-> table relationship which can all be managed automatically with Dapper and / or Contrib?

1
xampl9•

For simple selects the SQL is trivial - select * where key = myvalue You can have more complex SQL of course, and that will be embedded into your code. I've worked places where they went to extreme lengths to pull the SQL out into config files, text files, etc. and it never got us the promised benefits. So basically, forget all that, just put the SQL in the code and be done with it.

Mapping the column names to your data entity properties is what Dapper does. As long as the names match, it does it for you. It also knows about special cases like keys being named {tablename}Id -- so luck doesn't enter into it -- it's planning. :)

2
bhrgunatha•

Thanks, I appreciate your answer.

Sure it's planning, but in my case I also have to integrate legacy database tables, so it's not all plain sailing.

I was wondering whether I would write a tool to generate the SQL statements, keep them in a file or as a bunch of string constants. It's nice to have some insight to see what other people are doing.

1
xampl9•

If you've already got the tables, then just create the data entities around their definitions. As long as they're not too horrible, you'll be in good shape.

You also have the option of creating SQL views to hide some of the awfulness. Or stored procedures. As long as the result set columns match the entity in your code, Dapper will map it.

2