Designing an app for an ORM. Partial rant from a frustrated dev…

I am big on maintenance. I think it is the single most important issue with any application. That being said, I like the idea of using an ORM. I really think the maintenance aspect of an ORM is truly something not to be ignored. At work, we still use raw ADO.NET. Hand-rolled. We have some code generators that transform an XML file with SQL queries in it into static methods that return DataTables and DataViews… I hate this… for what I think are obvious reasons (No strong typing, you don't know what you have in the DT, unable to test methods, etc). The issue is whenever I bring up an ORM, the people above me get in a tizzy about how "slow" they are and how they will hinder performance. The big issue isn't always that they perform slower (some negligibly–looking at you Dapper) but rather that our queries are "so dynamic" that returning a strong object like a User to represent a record in the Users table is unnecessary and returns too much data.

I think it's an error in the design of the app, and possibly the logic of my peers. While it is true that some queries would potentially return more data than necessary, at worst it would only be a few columns of data. Or… we could restructure things in the UI to fit the data we returned? Or we could create more types that weren't direct 1 to 1 correlations to the DB… Just thinking out loud.

Anyway, what have you all done to maximize performance with an ORM? I know they can be performant, you may have to get used to them, though. I've used Dapper and Entity Framework–both of which I like. Any tips, ideas, thoughts, rants, comments? I am so frustrated arguing about things like this (ORMs are not the only argument… SOLID code and Unit Testing are a big ones too).

Just needed to rant.

by BlackFlash via /r/csharp

Leave a Reply