• Ben Johnston (github)

    The issue here isn't the fact they used an ORM, its the fact that they have 2 tables with exactly the same schema with different names. Truly impressive

    Also frist

  • Jonathan (unregistered)

    To me this seems to be more of an OO rather than ORM issue, inheritance is very often used inappropriately. It's probably made worse by them using an ORM as they may be more "disconnected" from what they're inflicting upon their database, but really, the problem is these people don't understand the implications of their dev decisions.

    As someone who has worked with C# and ORMs for over 10 years now, I would say that more often than not, using a good ORM is a better choice than the alternatives. My experience is that people who proclaim that ORMs are bad, are actually proclaiming that bad devs using ORMs are a big problem, their argument is generally along the lines of "if they didn't have an ORM, then they would be more aware of how a database works", i.e. the core problem is that devs don't understand databases properly and in turn how they should build their systems to work well with them.

    However, lack of an ORM in a strongly typed language like C# brings different kinds of issues, particularly that there is no compile time safety in manual SQL query strings compared to LINQ, and relatedly, changing your database schema is way harder. With EF in C#, I can rename a property (and by implication the underlying database column name) of my entity using a refactor tool, which will update all queries against that property, I then have EF generate a DB migration to update the schema, all-in-all possibly as quick as a 10-minute exercise. I suspect most people without an ORM with a system beyond a certain size wouldn't even consider such a refactor, whereas for me if I feel my domain would be more clear with a concept renamed, I can just go ahead and do it at minimal cost.

    The other common complaint I hear about ORMs is their performance. This has not been a problem for me in practice, when we design our entities we do so with UML and how things will work at a database schema level is a key consideration, this solves 99% of ORM performance issues.

    Continued...

  • TheCPUWizard (unregistered)

    If you are programming in an Object Oriented Language, and are using a Relational Database - to DO BY DEFINITION have an ORM.... It may be explicit sql with string concatenation in the event handlers of the UI, but it is still a model connecting the two....

    Now as to the more common ones [such as Entity Framework], it is is the same as any other case. I am currently working on one project that has 18 different Object Types that must be persisted [it will eventually be well over 10x that amount]. There are already over 3500 low level tests [written in a unit testing framework, yet not strictly unit tests] just on the configuration of the ORM...

    Some of these tests involve intercepting the generated SQL and performing analytics, other involve performance measurements against targeted specifications...

    An error like a table name not matching the paradigm as defined would immediately be caught and not even be pushed to a remote repository.

  • Jonathan (unregistered)

    ...continued from above.

    Another performance concern I often hear raised is that it's really easy to create LINQ which translates to terrible SQL queries, while this is true, it's super small percentage of queries where this has landed up being a problem and we're still saving LOADS of time with all the other queries which are absolutely fine. In such cases, just go fix the bad LINQ and if it absolutely can't be solved nicely with LINQ, EF allows you to give it a handwritten SQL query.

    The final performance issue I have encountered has been with bulk insertions / updates. EF entity tracking can certainly be an issue here, but again as above for most system, this is almost always a super small percentage of the total use cases and you can always fall back to alternatives on a case by case basis, still reaping the benefits of EF on the other 99% of your system.

  • (nodebb)

    This seems more like someone wanted to use some properties in another class, and didn't think to have a base class for both of them.

  • (nodebb) in reply to Jonathan

    To me this seems to be more of an OO rather than ORM issue

    This was exactly the thought I had when I read the article.

  • (nodebb)

    Another performance concern I often hear raised is that it's really easy to create LINQ which translates to terrible SQL queries

    That's not a LINQ issue or even a general ORM issue. As evidence, I will point out that it is easy to write SQL queries that translate to terrible SQL queries. You only have to look at the SQL related articles on this web site to understand that.

  • MRAB (unregistered)

    "Idosynchracies" is an idiosyncratic way of spelling "idiosyncrasies".

  • (nodebb) in reply to jeremypnet

    Sorry I disagree. ORMs (usually) "hide" what queries they generate, trying to accommodate whatever LINQ (or whatever) you throw at them, and it often results in bad queries. Should developers test (using something like SQL profiler) to make sure the queries are sensible? Yes. But while for some queries and some ORMs adjustments can be made to improve the query, for others it's impossible - the solution would be to change the ORM or not use one.

    That's just the queries - then there is the problem of "state tracking". This is one of the most infuriating "features" (more like anti-features) of the most popular ORMs - the whole "unit of work" and automatic commitment of changes. It almost never works with any set of changes other than the most basic ones. I personally had to completely drop the ORM from one project for this reason alone (I went with a combination of Dapper and home-grown simple INSERT/UPDATE/DELETE generators).

    I do agree with others though that in this case, the much bigger problem is the poor class inheritance, than ORMs.

    Addendum 2024-06-20 12:29: PS. Before suggesting I try ORM X which is better than the ORMs Y and Z, I assure you, I've tried them all, even names most people probably never heard before.

  • (nodebb)

    My view for several years now has been this: Use an ORM for the simple CRUD stuff at which it excels. This saves you a lot of effort because of strong types/IDE autocomplete/etc. It also covers about 80% of what you need to do. But don't hesitate to drop back into raw sql for trickier tasks where the ORM begins to struggle.

  • LZ79LRU (unregistered)

    ORM's are not bad. They are a tool. A tool is neither good nor bad, it just is.

    What's bad is the way the tool is used. And the issue in this case, like in many others is that a tool that is meant to make people who know what they are doing more productive is instead used to allow people who really don't know what they are doing to do the same job with predictable results.

    If a developer understands how DBs work, understands SQL and is generally qualified to do things without an ORM than the ORM is a tremendous tool that increases productivity. If he does not than it's a magic box that somehow databases your stuff that you put on the pile of magic boxes you use at work in your copy paste google-overflow shop.

    Evil lurks in the frameworks of tomorrow just as it did in the gotos of yesteryear. But it was newer the code that was harmful.

  • Annoyed (unregistered)

    The other WTF here is that people are still saying legos instead of lego which is the correct term!

  • Old lurker (unregistered) in reply to LZ79LRU
    ORM's are not bad. They are a tool. A tool is neither good nor bad, it just is.

    You apparently never had to deal with a flat screwdriver that got its tip damaged or bent.

    That doesn't mean the rest the rest of your post is wrong. ORMs have their uses depending on who put it in their toolbox and I agree with your assessment. But your ice cream koan was poorly thought out.

  • LZ79LRU (unregistered) in reply to Old lurker

    Yea, I forgot to add the chocolate flavored sprinkles. :)

  • Klimax (unregistered) in reply to Mr. TA

    How about Linq2DB. By content of your post, pretty sure you didn't use it… (Well ,it is much lighter than most of standard ORMs)

  • Klimax (unregistered) in reply to Old lurker

    I damaged only one and that was through un-screwdriver use. And still it works as screwdriver...

  • (nodebb)

    Definitely a mis-match between OO and what the database looks like. Kinda surprised the story isn't about how this bit a dev and bit them badly.

    I worked on a codebase not so long ago that was very heavy with inheritance. But it's major mistake was the object at the top of the tree. It was the database connector. facepalm Someone mangled the ideas of "has-a" and "is-a".

  • Dovregubben (unregistered)

    Legos? Everyone should be aware by now the plural form is legoes 🧌

Leave a comment on “Extended Models”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article