You should make that into a blog. Plenty there to consider. On 17 Sep 2016 11:04 AM, "Greg Low (罗格雷格博士)" <g...@greglow.com> wrote:
> Hey Dave and all, > > > > “The great” -> hardly but thanks Dave. > > > > Look, my issues with many of these ORMs are many. Unfortunately, I spend > my life on the back end of trying to deal with the messes involved. The > following are the key issues that I see: > > > > *Potentially horrid performance* > > > > I’ve been on the back end of this all the time. There are several reasons. > One is that the frameworks generate horrid code to start with, the second > is that they are typically quite resistant to improvement, the third is > that they tend to encourage processing with far too much data movement. > > > > I regularly end up in software houses with major issues that they don’t > know how to solve. As an example, I was at a start-up software house > recently. They had had a team of 10 developers building an application for > the last four years. The business owner said that if it would support 1000 > concurrent users, they would have a viable business. 5000 would make a good > business. 500 they might survive. They had their first serious performance > test two weeks before they had to show the investors. It fell over with 9 > concurrent users. The management (and in this case the devs too) were > panic-stricken. > > > > Another recent example was a software house that had to deliver an app to > a government department. They were already 4 weeks overdue and couldn’t get > it out of UAT. They wanted a silver bullet. That’s not the point to then be > discussing their architectural decisions yet they were the issue. > > > > I was in a large financial in Sydney a while back. They were in the middle > of removing the ORM that they’d chosen out of their app because try as they > might, they couldn’t get anywhere near the required performance numbers. > Why had they called me in? Because before they wrote off 8 months’ work for > 240 developers, the management wanted another opinion. > > > > Just yesterday I was working on a background processing job that processes > a certain type of share trades in a UK-based financial service > organisation. On a system with 48 processors, and 1.2 TB of memory, and 7 x > 1 million UK pound 20TB flash drive arrays, it ran for 48 minutes. During > that time, it issued 550 million SQL batches to be processed and almost > nothing else would work well on the machine at the same time. The > replacement job that we wrote in T-SQL issued 40,000 SQL batches and ran in > just over 2 minutes. I think I can get that to 1/10 of that with further > work. Guess which version is likely to get used now? > > > > *Minimal savings yet long term pain* > > > > Many of the ORMs give you an initial boost to “getting something done”. > But at what cost? At best, on most projects that I see, it might save 10% > of the original development time, on the first project. But as David > pointed out in his excellent TechEd talk with Joel (and as I’ve seen from > so many other places), the initial development cost of a project is usually > only around 10% of the overall development cost. So what are we talking > about? Perhaps 1% of the whole project? Putting yourself into a long-term > restrictive straightjacket situation for the sake of a 1% saving is a big, > big call. The problem is that it’s being decided by someone who isn’t > looking at the lifetime cost, and often 90% of that lifetime cost comes out > of someone else’s bucket. > > > > *Getting stuck in how it works* > > > > For years, code generated by tools like Linq to SQL was very poor. And it > knew it was talking to SQL Server in the first place. Now imagine that > you’re generating code and you don’t even know what the DB is. That’s where > EF started. Very poor choices are often made in these tools. The whole > reason that “optimize for ad hoc workloads” was added to SQL Server was to > deal with the mess from the plan cache pollution caused by these tools. A > simple example is that on the SqlCommand object, they called AddWithValue() > to add parameters to the parameters collection. That’s a really bad idea. > It provides the name of the parameter and the value, but no data type. So > it used to try to derive the data type from the data. So SQL Server would > end up with a separate query plan for every combination of every length of > string for every parameter. And what could the developers do to fix it? > Nothing. Because it was baked into how the framework worked. The framework > eventually got changed a bit to have more generic sizes but still never > addressed the actual issues. > > > > *Getting stuck with old code* > > > > SQL Server 2008 added a bunch of new data types. Spatial was one of my > favourites. When did that get added to EF? Many, many, many years later. > What could the developers do about it? Almost nothing except very hacky > workarounds. When you use a framework like this, you are totally at the > mercy of what its developers feel is important, and that’s if they haven’t > already lost interest in it. When you code with a tool that was targeted > cross-DB, you usually end up with a very poor choice of data types. You end > up with lowest common denominator of everything, or you end up with > something that doesn’t fit well with the framework. > > > > Many of the authors of the frameworks quickly lose interest. Do you want > to be stuck with it? > > > > *Summary* > > > > Look, I could go on for hours on this stuff and on what I’ve seen. As I > mentioned, it depends what you’re building. But if you’re taking > architectural advice from someone who hasn’t built real systems at scale, > at least get further opinions. “Oh I don’t want to write all that > boilerplate code” I hear people say. Sure. I get that but are you incapable > of code-generation? At least give yourself control over how the code works. > And that’s mostly a one-time cost. You get to use it again, project after > project. But at least if you don’t like it, you can fix it. > > > > I also see a lot of nonsense written about not wanting business logic in > stored procedures. I love people who have strict rules about that. They > keep us in business. “We don’t have people with strong T-SQL skills” I hear > you say. When you have a room full of devs that are clones of each other, > the lack of T-SQL skills isn’t the problem. The hiring decisions were. > Yesterday I was in an organisation with around 500 developers. I’d say > there are almost 2 people who are very data focussed yet data is at the > core of everything they do. It’s good for me. Those devs can generate poor > code faster than a handful of us can ever fix it. > > > > *Future* > > > > Also worth noting that if you want real performance from upcoming DB > engines, you might want to rethink that. Even DocumentDB that others have > mentioned has a concept of a stored procedure within the engine. You write > them in Javascript. But there’s a reason they are there. > > > > But in SQL Server 2016, this is even more stark. I have simple examples on > SQL Server 2016 where a batch of code sent from an app executes in 26 > seconds. If I move the table to in-memory, it runs in 25.5 seconds. If I > move the code to a natively-compiled stored procedure, it runs in 60 > milliseconds. > > > > If you are building toy apps ie: a replacement for CardFile, none of this > matters but I live in a world where it really, really matters. And so do > the vast majority of software houses that I spend time in. > > > > Your call. > > > > 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 *David Connors > *Sent:* Friday, 16 September 2016 1:20 PM > *To:* ozDotNet <ozdotnet@ozdotnet.com> > *Subject:* Re: Entity Framework - the lay of the land > > > > On Fri, 16 Sep 2016 at 11:56 Greg Keogh <gfke...@gmail.com> wrote: > > The people who think that ORMs are a good idea have a code-centric view of > the world. > > > > Stored procs! > > > > I know, right? Finally, someone who shares my enthusiasm! > > > > [ ... ] > > > > Databases are unlikely to have a structure that suits coders. > > > > THIS ^^ > > > > The goal of writing good quality / low TCO software is not to ensure that > things suit a given coder's predilections along the way. > > > > What can bridge the "impedance" gap? Something has to. > > > > I agree. It is called effort. > > > > It doesn't matter how much you like stored procs, you still have to get > stuff in and out of them across the gap to the coder's classes. How do > procs help? Are you proposing that more business logic be moved into procs? > > > > It isn't a case of me likely stored procs, it is a case of them a > declarative data tier both in terms of its state and also the paths of > execution that affect it day to day. The things that change the state of > the app become entirely deterministic as opposed to whatever BS EF cooks > up. > > > > If so, that way lies madness, as you can't easily integrate proc code into > source control, testing, versioning, builds, etc. > > > > File -> New -> Project -> SQL Server Database Project. Prepare to be > amazeballsed. > > > > I've seen whole apps written in T-SQL, and it's quite frightening. > > > > I'm not advocating writing whole apps in T-SQL. Stored procs need to be > short and punchy unless you want to spend your life diagnosing deadlocks. > > > > David. > > > > > > -- > > David Connors > da...@connors.com | @davidconnors | LinkedIn | +61 417 189 363 >
