What are the benefits of using ORM?

Question

As a web developer who wants to switch from PHP sites with manual coding to wireframe-based sites, I discussed a lot of the advantages of one ORM over another. It seems useful for projects of a certain (?) Size and even more important for enterprise-level applications.

What does he give me as a developer? How will my code be different from the individual SELECT statements that I am using now? How will this help with access to the database and security? How to find out about the database schema and user credentials?

Edit: @duffymo pointed out what should have been obvious to me: ORM is only useful for OOP code. My code is not OO, so I did not encounter problems that ORM solves.

Answer 1

I would say that if you are not dealing with objects, it makes little sense to use ORM.

If your relational tables / columns display 1: 1 with objects / attributes, there is not much point in using ORM.

If your objects do not have a 1: 1, 1: m or m: n relationship with other objects, there is not much point in using ORM.

If you have complex, manually configured SQL, it makes no sense to use ORM.

If you decide that your database will be stored as your interface, there is not much point in using ORM.

If you have a complex legacy scheme that cannot be reorganized, it makes no sense to use ORM.

So here is the opposite:

If you have a solid object model, with relationships between objects that are 1: 1, 1: m and m: n, do not have stored procedures, and like dynamic SQL that will provide you with an ORM solution, be sure to use ORM.

Solutions like these are always a choice. Choose, implement, measure, evaluate.

Answer 2

ORMs are inflated for solving data access problems. Personally, after using them in an Enterprise Project, they are far from a solution for Enterprise Application Development. Perhaps they work in small projects. Here are the problems we encountered in them: nHibernate:

• Configuration: ORM technologies require configuration files to map table schemas to object structures. In large enterprise systems, configuration grows very quickly and becomes extremely difficult to create and manage. Saving the configuration also becomes tedious and overwhelming, as requirements and business models are constantly changing and evolving in a flexible environment.

• User requests. The ability to map user requests that do not fit into any particular object is either not supported or not recommended by infrastructure providers. Developers are forced to find jobs by writing down special objects and queries or writing their own code to get the data they need. They may have to use stored procedures regularly for something more complex than a simple Select.

• Property binding: These frameworks require the use of proprietary libraries and query languages ​​for user objects that are not standardized in the computer science industry. These proprietary libraries and query languages ​​associate the application with a specific provider implementation with little or no flexibility to change, if necessary, and cannot interact with each other.

• Object query languages. To execute queries in the object model, new query languages ​​are provided, called object query languages. They automatically generate SQL queries against the database, and the user abstracts from the process. For object-oriented developers, this may seem useful because they believe that the problem of writing SQL has been resolved. The practicality problem is that these query languages ​​cannot support some of the intermediate or extended SQL constructs required by most real-world applications. They also prevent developers from customizing SQL queries as needed.

• Performance. ORM levels use reflection and introspection to create and populate objects with data from a database. These are expensive operations in terms of processing and adding to the performance degradation of matching operations. Object queries that are converted to create non-optimized queries without the possibility of tuning them, which leads to significant performance losses and overloading database management systems. Tuning SQL performance is nearly impossible, as the frameworks provide little flexibility over the management of SQL that gets auto-generated.

• Tight relationship: this approach creates a tight relationship between model objects and database schemas. Developers do not want a one-to-one correlation between database fields and class fields. Changing the database schema affects ripples in the object model and display configuration, and vice versa.

• Cache. This approach also requires the use of object caches and contexts that are necessary for maintian, and to track the state of the object and reduce the number of database accesses for cached data. These caches, if they are not supported and synchronized in a tiered implementation, can have significant consequences in terms of data accuracy and concurrency. Often, to fix this problem, you need to connect third-party caches or external caches, which increases the load on the level of data access.

For more information about our analysis, you can read: http://www.orasissoftware.com/driver.aspx?topic=whitepaper

Answer 3

At a very high level: ORMs help reduce the impedance mismatch of object-relational resistance. They allow you to store and retrieve full live objects from a relational database without having to do a lot of parsing / serialization.

What does he give me as a developer?

For starters, this helps you stay dry. Either you, or the model diagram, are authorized, and the other is automatically generated, which reduces the number of errors and the number of code labels.

This helps with marshaling. ORMs usually marshal the values ​​of individual columns into appropriate types so that you do not have to parse / serialize them yourself. In addition, it allows you to retrieve a fully formed object from the database, and not just row objects that you must wrap yourself.

How will my code be different from the individual SELECT statements that I am using now?

Since your queries return objects, not just strings, you can access related objects using attribute access rather than creating a new query. You can usually write SQL directly when you need to, but for most CRUD operations, ORM will make it easier for code to interact with persistent objects.

How will this help with access to the database and security?

Generally speaking, ORMs have their own APIs for building queries (for example, access to attributes) and are therefore less vulnerable to SQL injection attacks; however, they often allow you to inject your own SQL into generated queries so that you can do weird things if you need to. With such an embedded SQL, you are responsible for disinfecting yourself, but if you avoid using such functions, ORM should take care to automatically clear user data.

How to find out about the database schema and user credentials?

Many ORMs come with tools that will test the circuit and create a set of model classes that will allow you to interact with objects in the database. [Database] User credentials are usually stored in the settings file.

Answer 4

If you write your level of data access manually, you are essentially writing your own function with poor ORM.

Oren Eini has a good blog that summarizes the main features that you might need in your DAL / ORM, and why he writes his own, becomes a bad idea after a while: http://ayende.com/Blog/archive/2006/ 05/12 / 25ReasonsNotToWriteYourOwnObjectRelationalMapper.aspx

EDIT: OP commented in other answers that its code base is not very object oriented. Working with object mapping is just one aspect of ORM. The Active Record pattern is a good example of how ORMs are still useful in scenarios where objects map 1: 1 to tables.

Answer 5

I can't speak for other ORMs, just Hibernate (for Java).

Hibernate gives me the following:

• Automatically updates the schema for production system tables at run time. Sometimes you still have to manually update some things.
• Automatically creates foreign keys that prevent you from writing bad code that creates lost data.
• Implements pooling. Several connection pool providers are available.
• Cached data for quick access. Several caching providers are available. It also allows you to combine multiple servers to help you scale.
• Makes access to the database more transparent so that you can easily transfer the application to another database.
• Make queries easier to write. The following query, which usually requires you to write “join” three times, can be written as follows:
  • "from invoice i, where i.customer.address.city =?" it retrieves all invoices with a specific city.
  • returns a list of invoice objects. Then I can call invoice.getCustomer (). GetCompanyName (); if the data is not already in the cache, the database is automatically queried in the background.

You can redesign the database to create a sleep mode diagram (have not tried it yourself), or you can create a diagram from scratch.

Of course, there is a learning curve, as with any new technology, but I think it's worth it.

If necessary, you can switch to a lower level of SQL to write an optimized query.

Answer 6

The best benefits:

• Database abstraction
• API Oriented Mentality Design
• High level == Less worry about the fundamental level (thought about it for you)

I have to say that working with ORM is really an evolution of database driven applications. You worry less about the SQL code you always write, and more about how interfaces can work together to make a very simple system.

I like not to worry about INNER JOIN and SELECT COUNT (*). I'm just working on my high-level abstraction, and at the same time doing database abstraction.

Having said that, I never encountered a problem when I needed to run the same code on several database systems at the same time. However, not to say that the case does not exist, this is a very real problem for some developers.

Answer 7

Most databases use relational databases that are not directly converted to objects. What the relational Mapper object does is take the data, create a wrapper around it with utility functions for updating, deleting, pasting and other operations that can be performed. So instead of thinking of it as an array of strings, you now have a list of objects that you can manipulate like any other, and just call obj.Save () when you're done.

I suggest you take a look at some of the ORMs used, my favorite is the ORM used in the python structure, django . The idea is that you write a definition of how your data looks in the database, and ORM takes care of validation, validation and any mechanics that must be performed before the data is inserted.

Answer 8

Personally, I have not had much experience using ORM technology to date. I currently work for a company that uses nHibernate, and I really can't handle it. Give me a stored procedure and DAL any day! More code of course ... but also more control and code that is easier to debug - from my experience using the earlier version of nHibernate, it should be added.

Answer 9

What does he give me as a developer?

Saves your time, since you do not need to encode part of access to db.

How will my code be different from the individual SELECT statements that I am using now?

You will use either attributes or xml files to define class mappings in database tables.

How will this help with access to the database and security?

Most frameworks try to adhere to db best practices where applicable, such as parameterized SQL, etc. Since implementation details are encoded in the structure, you do not need to worry about that. For this reason, however, it is also important to understand the structure you are using and be aware of any design defects or errors that may open unexpected holes.

How to find out about the database schema and user credentials?

You always specify the connection string. Infrastructure providers (e.g. SQL, Oracle, MySQL-specific classes) provide an implementation that queries the db schema, processes class mappings, and creates / executes the db access code if necessary.

Answer 10

Using ORM will remove dependencies from your code in a particular SQL dialect. Instead of interacting directly with the database, you will interact with an abstraction layer that provides isolation between your code and the database implementation. In addition, ORMs typically provide protection against SQL injection by constructing parameterized queries. Of course, you could do it yourself, but it's nice to have a framework guarantee.

ORMs work in one of two ways: some discover a schema from an existing database — the LINQToSQL developer does this — others require you to map your class to a table. In both cases, once the schema has been displayed, ORM can create (recreate) the structure of your database for you. Database permissions probably still need to be applied manually or through native SQL.

Typically, credentials supplied programmatically through the API or using a configuration file — or both — by default come from a configuration file, but can be overridden in code.

Answer 11

For a podcast that discusses ORM in detail, see the following link. http://se-radio.net/podcast/2008-12/episode-121-or-mappers-michael-ploed

Answer 12

Although I completely agree with the accepted answer, I think that it can be changed with light alternatives.

• If you have complex, manually configured SQL
• If your objects do not have a 1: 1, 1: m or m: n relationship with other objects
• If you have a complex legacy scheme that cannot be reorganized

... then you may need a lightweight ORM where SQL is not to hide or abstract to such an extent that it is easier for you to write your own integration with the database.

Here are a few of the many reasons why the development team at my company decided that we needed to make a more flexible abstraction to put on top of JDBC.

There are many open source alternatives that do the same, and jORM is our proposed solution.

I would recommend evaluating some of the strongest candidates before choosing an easy ORM. They differ slightly in their approach to abstract databases, but may look similar from top to bottom.

• jORM
• Activejdbc
• ORMLite

Answer 13

my concern for ORM frameworks is probably what makes it attractive to many developers.

nameley, that it eliminates the need to "take care" of what happens at the DB level. Most of the problems that we observe in the daily work of our applications are related to database problems. I am a little worried about the world, which is 100% ORM, that people will not know what queries get into the database, or if they do, they are not sure how to change or optimize them.

{I understand that this may be a contradictory answer :)}