Our Love/Hate relationship with ORMs
•Als PPTX, PDF herunterladen•
0 gefällt mir•62 views
Whether we like it or not we use ORMs a lot. We know that their advantages come with many disadvantages, we still use them though, just to spare precious development time. But in the end we burn a lot more on maintenance, performance enhancements and obscure hacks. So do they really worth the fuss?
Weitere ähnliche Inhalte
Ähnlich wie Our Love/Hate relationship with ORMs
Ähnlich wie Our Love/Hate relationship with ORMs (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Our Love/Hate relationship with ORMs
- 2. 2CONFIDENTIAL AGENDA The LOVE1 The HATE2 And the ALTERNATIVES3
- 4. 4CONFIDENTIAL The LOVE Why do we use ORMs? • To use the Domain Model pattern • To make data access more abstract and portable • To move the BL to DAL • To avoid writing SQL queries
- 5. 5CONFIDENTIAL The LOVE The benefits of ORMs • LINQ • Object mapping • IntelliSense • Compile-time query checking
- 6. 6CONFIDENTIAL The LOVE Some additional benefits • Change tracking • Code first • Boilerplate code generation • Transaction management • Lazy loading • Caching
- 8. 8CONFIDENTIAL The HATE Why do we hate using ORMs? • They are bloatware • They are blackbox • They tend to be slow • They fail to compete against complex queries • They are not the adequate way to do relational queries
- 12. 12CONFIDENTIAL The ALTERNATIVES What should I do? • Use object stores (NoSQL) • Accept it • Choose Entity Framework • Choose a microORM • Go with a custom solution
Hinweis der Redaktion
- To use Domain Model pattern: About a decade ago Udi Dahan said: „There is one main reason to use an object/relational mapper, and that is to implement the Domain Model pattern” Which is a nice thing, but be honest, do we use ORMs because of that? Hell no. To make data access more abstract and portable That’s another nice thing, and a common pro when people are talking about the advantages of ORMs. They know how to generate vendor-specific SQL queries so you don’t have to worry about that. But let me ask it again: do we you ORMs because of that? No, not really. It’s like choosing jQuery just because it hides all the obscure differences between various browser types and versions. As I said, it’s a nice thing, a nice to have feature, and a big pro, but it surely isn’t the main driver behind choosing it. To move the BL to DAL Now we are getting closer. Back then all the business logic were in stored procedures, functions, triggers and whatnot. And everybody who ever worked on a legacy project knows how much pain in the ass that can be. Poorly written stored procedures with zero documentation, no version controlling whatsoever and hacks, hacks everywhere. The urge to move and encapsulate the business logic a bit higher, to write it down in a readable and maintainable OOP language is really strong in developers. And if we do that we have to introduce domain models and then we can go back to Udi’s words and use ORMs. That’s a strong argument, but it’s still not the final answer. To avoid writing SQL queries Now that’s the real driver here! We are kinda lazy, we don’t like to write SQL queries, LINQ is much cooler anyway, plus query literals are pretty ugly too. We can also spare writing a lot of lame CRUD methods, we don’t have to map types, and we can have code first too! Those are the real benefits here! Everything else is just a mixture of buzzwords and convenient excuses. SQL makes our code noisy and ugly and we do everything in order to avoid that.
- From another aspect let me just collect the most important benefits of ORMs we really like LINQ LINQ is the shit, right? We like its fluent API, its very essence of elegance. LINQ is one of the most coolest feature of C# and we love to use it wherever we can. And even better if it can hide those ugly SQL queries we don’t like. It’s a win-win situation, right? Object mapping The second most important feature, because there isn’t anything more boring and annoying than to bother with type mapping. Map booleans to bits, enums to integers, byte arrays to blobs or varbinaries and all of those vice versa, to suck with nullables, format datetimes and all those annoying things. An ORM can take care all of those (with some limitations of course) and you don’t have to worry about to find the SQL equivalent of any .NET type. IntelliSense Code completion is another important feature, I’m sure I don’t have to explain why. It helps to avoid typos and on another level, if you don’t have to use string literals it’s much easier to do refactors. Compile-time query checking It’s kinda related to the previous one and needs to explanation. Highly improves code quality, you don’t have to check the query syntax, it gives you a protection against SQL injection attacks, etc. Just like all the above it spares you a lot of precious development time.
- It just doesn’t end, does it? :) ORMs provide features on a so wide range that it’s nearly impossible to collect all and they hold different importance to different people. Some of these are even in the grey area, they can be both pro or con. For instance lazy loading is the ORM equivalent of the auto-correct on mobile phones, meaning they treat the symptoms only not the real cause behind it. The same goes for caching, of course. These features exist only to speed up things. And if we are talking about Code first. It’s a pretty convenient way to create databases locally on the dev environments, but just simply doesn’t work in case of a production environment. Or it actually can, but it’s a really-really bad anti-pattern.
- They are bloatware Huge ORMs with hundreds of thousands lines of code know a lot, have a lots of features and they put a massive overhead on your solution. They are so complex and robust that it takes infinite amount of time to master them. Most of us just aren’t qualified enough to use them properly. Alternatively this led to the rise of the microORM solutions where they threw out the unnecessary and most problematic features and they focus on the one thing ORMs should be about: object-relation mapping. Therefore they got rid of all the fancy features, even the LINQ support and they provide a solution where you have to write your own queries – bringing back the unwanted code smells – and it will just take care of the mapping and the mapping only. The third way is – any many critics suggest that – you should come up with your own lightweight alternative. We did that on our project recently, I’m going to talk about that later. They are blackbox What people usually hate about ORMs that they don’t exactly know how they work, a lots of logic is hidden, and top of that if it generates ugly, unreadable and often inoptimal SQL queries, and you cannot really do anything against it, because they provide minimal customizability or extensibility. Most of the ORMs are following the closed/closed principle, they are both closed for modification and extension. Which immediately leads to hacking, trust me, I’ve been there many-many times. :) So ORMs tend to be blackboxes, you can never be sure what truly happens in them, and which input’s going to cause a terrible outcome. Plus as I mentioned earlier, it’s really hard to master them, people can even suffer loss in developer productivity whilst they learn to program with a specific ORM. They tend to be slow This is one of the most common con out there. They hold a huge overhead and on top of that they can be slow as hell too. Why? There can be many reasons: They don’t generate an optimal query, making it unnecessarily complex or in some weird cases they are just unable to filter everything on the SQL side, so they just read all the data and filter them later in memory, which is no wonder that tend to be slow The latter isn’t just slow because you move unnecessary data between the channels, but because you have to map a lot of unnecessary objects. Remember, there is reflection behind most ORMs, plus you waste memory, you give more job to the GC, etc. They are not designed for bulk operations, so if you are working on a project where performance is one of the highest quality attribute you are going to have a baaaad time. They fail to compete against complex queries Another important problem that when it comes to complex queries they simply fail. Think about joins, nested queries, unions, etc., it’s really difficult to manage them with ORMs. Especially when performance is a critical thing. In case of my recent project I had to „extend” LINQ2SQL with a lot of custom solutions to support these kind of things. And even though I failed with joins. But at least I was able to create custom SQL query generator to support nesting, unions and bulk operations as well. With nesting I was able to avoid some scenarios where the textbox examples use joins. So there’s a way to overcome these limitations, but it takes a lot of time and leads to a custom lightweight ORM solution I mentioned earlier, which of course has it’s own drawbacks. They are not the adequate way to do relational queries And last but not least here’s the biggest con of all time about ORMS. Relational data and object-oriented programming are essentially and fundamentally two different things. Mapping between them is hard, and sometimes even impossible. This approach violates all principles of object-oriented programming, tearing objects apart and turning them into dump and passive data bags. Some developers considers it an offensive anti-pattern because of this and claiming that the entire idea is wrong behind ORMs and that it’s invention was the biggest mistake of all time.
- Because this is the idea, right? That it should be that simple. Here are your objects, you map them (doesn’t really matter how complex and obscure logic is inside this box) and there you go, you can persist your data to the relational database.
- In reality it looks more like this. You cannot encapsulate database interaction inside of an object, instead it extracts it away, literally tearing a solid and cohesive living organism apart. In most cases the data is represented in a whole different structure than your code would need it, so you have to do constant magic and wizardry with the data, join them, split them, transform them, index them, cache them, etc. So in short objects are not an adequate way of expressing the results of relational queries, and the inadequacy of the mapping of queries to objects leads to a fundamental inefficiency in ORM-backed applications that is pervasive, distributed, and therefore not easily fixed without abandoning ORM entirely.
- These all lead to one ultimate question when you are about to start a project and ORM is an option: „What should I do?” Or, alternatively: „Is there a silver bullet?” But I guess you all know the answer for that one: „No”. Which means the ultimate answer for the ultimate question is also pretty simple: „It depends.” Use object stores (NoSQL) If your data is objects, you can always stop using a relational database. Just because SQL is the traditional way it doesn’t necessarily mean that you should stick to that. The world is currently awash with key-value stores that will allow you to hold elegant, self-contained data structures in huge quantities and they will be much faster than a relational database. Accept it If your data is relational in nature, you have to work with an existing database, or if you simply don’t have the expertise in your team, you can still accept the fact that ORMs come with a lot of drawbacks. In this case you have still three options left: Choose Entity Framework Or something the team already knows and can handle with care, like LINQ2SQL. But right now EF is the de facto standard in the .NET world, so that’s the easiest to go with. Try to avoid complex queries and hope for the best that the project won’t increase in complexity too fast. Because if it does, you end up delivering a slow and/or mixed up solution where you force your dev to use SQL instead here and there. Mostly where the performance is the most critical. Try to avoid using TPH (Table per hierarchy) or similar where you have to store inheritance in database. EF doesn’t handle those scenarios well making it even more slow and it has got ridiculous limitations. Choose a microORM If you don’t mind losing a lot of cool features using a microORM can be a good alternative. Personally I don’t like them because their fluent API is nothing like LINQ, but I understand they got rid of that for a reason. Anyway, as I mentioned, if you don’t mind writing SQL queries and pollute your code with a lot of literals then go ahead. Just keep in mind something: compared to Dapper LINQ 2 SQL has got absolutely minimal overhead, most of the queries can run on the same speed. I made a bunch of performance tests at the beginning of my current project and turned out that for us LINQ2SQL is the best choice, because it can run on the same speed as Dapper and we don’t have to write any SQL queries manually. It’s the real win-win, eh? Well, not exactly. Go with a custom solution Eventually we ended up developing a custom hybrid solution. As I mentioned earlier I had to „extend” LINQ2SQL to support all our needs. And there’s a big emphasis on the extend word, because we cannot speak about real extension here. My hybrid solution was that where LINQ2SQL lacked capabilities, I added new extension methods and we used them instead. But because LINQ2SQL is pretty sealed, it was easier to generate custom SQL queries than hack it to the core. Earlier I got so fed up with Entity Framework that I decided to write my very own ORM. Why? I just wanted to see how hard can it be to do it properly. And yeah, it’s hard. That’s the lesson learned here. :) So keep that in mind when you decide to go with a custom thing. But custom solution can be anything. You can even choose to do everything by yourselves, open direct SQL connections, map the datarows, create all the CRUD methods, etc. Nobody wants to do that, though. :) But if we are talking about the latter, the CRUD methods, I mentioned earlier that it’s a big pro on the ORM side that you don’t have to worry about the CRUD, the ORM takes care of that. However when you introduce the Repository pattern, which is quite famous nowadays, the CRUD methods simply come back. Which means you lose one of the perks of using ORMs anyway.
- And that’s all I wanted to share. As you can see there’s no silver bullet, ORMs have a lot of drawbacks, but we still need them, because they have their advantages. It’s just like SQL. There are a lot of other data storage options out there, but SQL is till alive and a lot of projects rely on it. And not just legacy projects. There are scenarios where using SQL is a good choice. Just like an ORM. Whether we love them or hate them.