Replacements to hand-rolled ADO.NET POCO mapping?

ado.net dapper massive petapoco simple.data

Question

I have written a wrapper around ADO.NET's DbProviderFactory that I use extensively throughout my applications. I also have written a lot of code that maps IDataReader rows to POCOs. However, as I have tons of classes the whole thing is getting to be a pain in the ass to maintain.

I have been looking at replacing the whole she-bang with a micro-orm like Petapoco. I have a few queries though:

  1. I have lots of POCOs that contain other POCOs in them as properties. How well does the Petapoco support this?
  2. Should I use a ORM like Massive or Simple.Data that returns a dynamic object and map that to a POCO?
  3. Are there any approaches I can take to the whole mapping of rows to POCOs? I can't really use convention-based tools as my database isn't particularly consistent in how it is designed.

Popular Answer

Could you use QueryFirst, or modify it? It takes your sql and wraps it in vanilla ADO code, generated at design time. You get fresh POCOs from your result schema every time you save your file. Additionally, you can choose to test all queries and regenerate all wrappers via the option in the tools menu. It's dependent on Sql Server and SqlClient, so unless you do some modification, you'll lose DbProviderFactory.




Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Is this KB legal? Yes, learn why
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Is this KB legal? Yes, learn why