Hi Grant et al, You're psychic, as I was going to post on this old topic later in the week, as I've rejigged my thinking a little in recent months.
I also used CodeSmith to make CRUD for a few good years and I was impressed by how easy it was. I used the netTiers templates, not handmade. What I liked about netTiers was that the CRUD was basically table-based and not over-engineered like many famous ORMs (including EF) and it just threw a really handy bridge at the lowest useful level between classes and tables. Maybe even David C wouldn't turn his nose up at that?! Both EF and netTiers support "deep loading" by effortlessly following joins, and that's about the only advanced feature of either of them that I ever used. In recent months in both hobby code and some real apps I faced that choice of where to swing the pendulum of manipulating data ... towards the database or towards the app code. I have decided that all basic data manipulation like WHERE, ORDER, OVER, JOIN, SELECT, etc should be done in stored procs and not in the ORM or app code. You just can't beat the performance and clarity of doing this in the DB. After all, that's what it's built for! And EF is great for simply mapping the procs to methods and DTO classes. I now put a fence up in my mind to put all basic data manipulation in the DB on one side and strictly business logic in the code on the other side. Sometimes you have to shred and knit DTOs, but that should be in app code as well. And Grant's concern about dependency on specific ORMs is quite valid. We have one app that heavily used EF v4 and the self-tracking entities, which were deprecated, and now we're stuck and can't get to EF6 without industrial effort. Imagine trying to completely change your ORM brand. So in summary I have decided for now that ORMs are still a real coding productivity boost, but only when used for basic CRUD and DTOs. *Greg K*
