O / R Mappers - Good or Bad

Question

I'm really torn right now between using O / R cards or just tied to traditional data access. For some reason, every time I bring out O / R cards, other developers shrink and talk about performance issues or how bad they are. What am I missing here? I am looking at LINQ to SQL and Microsoft Entity Framework. Are there any grounds for any of these claims? What things should I compromise if I want to use an O / R mapper. Thanks.

Answer 1

At first, this seems like an unrelated answer, but: one of my collateral interests is World War II fighters. All the fighting countries (USA, UK, Germany, USSR, Japan, etc.) created a war of different fighters. Some of them used radial engines (P47, Corsair, FW-190, Zero); some used liquid-cooled built-in engines (Bf-109, Mustang, Yak-7, Spitfire); and some used two engines instead of one (P38, Do-335). Some used machine guns, some used guns, and some used both. Some were even made from plywood, if you can imagine.

In the end, they all went very fast, and in the hands of a competent experienced pilot, they instantly shot you in a brand new ass. I don’t think that many pilots flew thinking: "Oh, this idiot is flying something with a radial engine, I don’t need to worry at all." Everyone understood that there are many different ways to achieve the ultimate goal, and each approach has its own particular advantages and disadvantages depending on the circumstances.

The discussion between ORM and traditional data access is this, and any programmer needs to be competent with both approaches and choose an option that works.

Answer 2

I struggled with this decision for a long time. I think I hesitated for two main reasons. Firstly, O / R-mappers represented a lack of control over what was happening in the critical part of the application, and secondly, because so many times I was disappointed with solutions that are surprising for a 90% case, but unhappy for the last 10%. Of course, everything works on a choice * from the authors, but when you cope with complexity and have a high volume critical system and your career is on the line, you feel that you need to have full control to configure each request template and bytes over the wire. Most developers, including myself, are upset the first time we run the tool, and we cannot do what we need, or our need deviates from the installed template supported by the tool. I will probably be flaming to mention some of the shortcomings in the tools, so I will leave it to that.

Fortunately, Anderson Imes finally convinced me to try CodeSmith with the netTiers template . (No, I do not work for them.) After more than a year, using this, I cannot believe that we have not done this before. My team uses Visual Studio DB Pro, and with each test, our continuous integration assembly produces a new set of data access assemblies. This automatically processes all the usual low-risk materials, but we can still write our own sprocs for complex bits and include them as methods for the generated classes, and we can also customize the templates for the generated code. I highly recommend this approach. There may be other tools that allow this level of control, as well as a new CodeSmith template called PLINQO, which uses LINQ to SQL under the hood. We have not yet studied (not necessary), but this general approach has many advantages.

Jerry

Answer 3

O / RM tools designed to work very well in most situations. It will cache objects for you, it will execute requests in packages, it has a very low level of optimized access to objects, which is faster than manually assigning values ​​to properties, they give you a very simple way to enable aspect-oriented programming options using modern technology, such as interceptors, it will manage the entity for you and help resolve conflicts and more.

Currently, the disadvantages of this approach, as a rule, are a lack of understanding of how everything works at a very low level. The most classic problem is "SELECT N + 1" ( link ).

I have been working with NHibernate for 2.5 years, and I still discover something new about it almost daily ...

Answer 4

Good. In most cases.

The performance benefit of using ORM in most cases outweighs the loss of control over data access.

There is not much who would avoid C # to program MSIL or Assembly, although that would give them more control.

Answer 5

The problem that I see with a lot of OR cards is that you get bloated domain objects that are usually associated with the rest of your data access infrastructure. Our developers also cope with this :) It is simply more difficult to transfer this object to another data access technology. If you use L2S, you can take a look at the generated code. It seems like a complete mess. NHibernate is probably one of the best in this. Your objects are completely unaware of your level of data access, if you design them correctly.

Answer 6

It really depends on the situation.

I went from a company that used a modified ORM for a company that did not use ORM and kept writing SQL queries all the time. When I asked for the use of ORM to simplify the code, I got this blank face-to-face look, followed by all its negatives:

• Its high color
• you do not have precise control over your requests and perform unnecessary
• there is a heavy object to display the table
• its not a dry code because you have to repeat your

on on

Well, after working there for several weeks, I noticed that:

• We had several requests that were almost the same, and many times, if there was an error, only a small part would be fixed.
• instead of caching common table queries, we would end up reading the table several times.
• We repeated ourselves on the spot
• We had several skill levels, so some queries were not written most efficiently.

After I pointed this out, they wrote "DBO" because they did not want to call it ORM. They decided to write one from scratch, rather than tweaking it.

In addition, many arguments stem from ignorance regarding the ORM that I feel. Each ORM I've seen allows you to create custom queries, and even after the ORM conventions, you can write very complex and detailed queries and, as a rule, are more readable for people. In addition, they are usually very dry, you give them your own scheme, and they calculate the rest, up to matching relations.

Modern ORM has many tools that will help you, for example, migration scripts, several types of databases that access the same objects so that you can take advantage of both NOSQL and SQL DB. But you must choose the right ORM for your project if you intend to use it.

Answer 7

First I got into the ORM mapping and data access layers from reading Rockford Lhotka books, C # business objects. He worked on the frame for DAL for many years. While his frames out of the box are very bloated, and in some cases, excessive, he has great ideas. I highly recommend the book to anyone looking at ORM cards. I was influenced by his book enough to pick up a lot of his ideas and build them into my framework and code generation.

Answer 8

There is no simple answer to this question, since each ORM provider will have its own particular pros and cons. Some ORM solutions are more flexible than others. It is the responsibility of the developer to understand this before using it.

However, take LinqToSql - if you are sure that you will not need to switch from SQL Server, then this solves many common problems observed in ORM devices. This allows you to easily add stored procedures (like static methods), so you are not limited to just created SQL. It uses deferred execution so you can efficiently bind queries. It uses partial classes so that you can easily add custom logic to the generated classes without worrying about what happens when you re-generate them. There's also nothing stopping you from using LINQ to create your own abstract DAL — it just speeds up the process. The main thing is that it facilitates the boredom and time required to create the main CRUD layer.

But there are also disadvantages. There will be a tight connection between your tables and classes, there will be a slight decrease in performance, sometimes you can generate queries that are not as efficient as you expected. And you are tied to SQL Server (although some other ORM methods are database agnostics).

As I said, the main thing is to be aware of the pros and cons before attaching your colors to a particular methodology.