I often wish there was a better lightweight or that generated chide for you from stored procs - dapper on steroids. Perhaps I should write one!
On 3 Jan 2017 5:31 PM, "Greg Low (罗格雷格博士)" <g...@greglow.com> wrote: > “ORMs are still a real coding productivity boost,” > > > > Are they though? I see them knock at best 10% off a dev project, and that > dev work is at best probably 10% of the lifetime cost of the project. > > > > So a 1% overall saving in project cost ends up determining and limiting so > many aspects of the overall project over its life? Not sure that’s any sort > of boost. > > > > Regards, > > > > Greg > > > > Dr Greg Low > > > > 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 > fax > > SQL Down Under | Web: www.sqldownunder.com | http://greglow.me > > > > *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@ > ozdotnet.com] *On Behalf Of *Greg Keogh > *Sent:* Tuesday, 3 January 2017 8:16 PM > *To:* ozDotNet <ozdotnet@ozdotnet.com> > *Subject:* Re: Entity Framework - the lay of the land > > > > 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* >
