I have used Entity Framework myself but generally simply map to stored procs. Some Linq occasionally creeps in, but the biggest gripe I have with EF is the lazy loading. It can get nasty very quickly generating ridiculous amounts of unnecessary traffic as it loads every linked object it comes across. At the very least if people are going to use EF, turn off lazy loading and use eager loading instead.
Stored procs are best, of course, as it's often much easier to get stored proc changes through change control in enterprises than code changes in an app, which requires virtually a compete redeploy. Things really slow down in the mapping layer, especially when you are custom loading related objects. Way to destroy performance. If you can return an EF stored proc results class without any extra mapping it can increase productivity. There is a natural boundary if returning the results from webapi calls to angular, for example. Of course, I think I lost a job recently because they thought lazy loading was the best thing since sliced bread. Deluded I think in thinking they were getting a productivity increase that wouldn't be offset by a massive maintenance bill and slow application. On 3 Jan 2017 4:16 PM, "Greg Keogh" <[email protected]> wrote: > 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* >
