To what extent is it not advisable to use an ORM?

Navigation
37

I'm working on a very large system using .NET (Asp.net MVC) application requires a critical level of performance . To what extent is it worth using an ORM? Is there any tool that I can compare in terms of ORM's performance and pure SQL?

I know there is a performance difference between pure SQL and ORM, I do not know if activerecord's or ORM's in general are slower compared to pure SQL, if you consider using an ORM, which one probably has the best performance : EF or NHibernate?

I know that everything also depends on the bank's structure and good practices, but in general for a very large system do I consider an ORM? Since the cost benefit in relation to system maintenance is much higher than not using

    
asked by anonymous 28.04.2014 / 21:38

3 answers

34

I am in favor of a mixed approach

  • Use ORM to the max to improve readability and productivity . In C # or VB.Net it is possible to use LINQ, which is an extraordinary tool in terms of productivity. The simpler the better.

  • When you need to increase performance, or when ORM does not offer the right tools for the job, further study the chosen ORM and search for information on the internet, and only then, go to SQL .

    ORM's usually allow you to use a SQL-like language, or allow you to use SQL with specific formatting, which is an intermediate point.

Which one to choose?

Working with both, NHibernate has more features, is more flexible, and has many tools and extension libraries, however EntityFramework is simpler and easier to use, and tools integrate with Visual Studio.

  • For a project that is born with LOW demand

    Choose between EntityFramework and NHibernate, in this case it can be reduced to a custom issue, ie use the one that is most familiar .

    If you have to learn one of them, I would choose EntityFramework , it uses more current technologies, and is evolving rapidly.

    And If you already know both, EntityFramework would also work, as it is simpler to work with, as well as having Visual Studio integration , which helps a lot in productivity.

  • For a project that is born with HIGH Demand

    For a project that is already born with a large data / user / expectation load (imagine a system for a company to manage thousands of employees), then I would still recommend NHibernate ... it is a technology that certainly will not leave nothing to be desired.

References

28.04.2014 / 22:00
23

About the Entity Framework

The implementation of DbSet<> causes the data context to load the database record only once during the Controller life cycle. Therefore, the performance difference between the system written with pure SQL for the system in Entity Framework becomes negligible if the database is normalized correctly (that is, with unique primary keys and avoiding unnecessary relationships such as tables that are updated from once in never, and can be replaced with Enums ). Because it is very simple, it is ideal for the beginning of development of a system. The disadvantage is the lack of support for other banks, such as Oracle, for example.

About NHibernate

It is a solution older than the Entity Framework, which came from Java when ORM started. It has more configuration options and works better with databases other than SQL Server. However, the approach to Code First is still a bit too prolix, which makes it slower than the Entity Framework to start a project in terms of productivity, being more recommended for large projects that are already implemented and work with large masses of data, which requires fine tuning of the settings.

To what extent is it not advisable to use an ORM?

This part is somewhat opinion-based, but initially I would say there are no restrictions, since ORM frameworks enable pure SQL execution in stages where there are performance bottlenecks. Therefore, neither productivity nor performance is compromised.

UPDATE

Oracle developed your data provider with the Entity Framework , finally. With this, the connectivity problem between Oracle and Entity Framework is over.

A tutorial was also written by the Oracle team to address any questions that might arise in the integration.

    
29.04.2014 / 21:29
4

ORM advocates will say that this does not apply to all projects: not everyone needs to perform complex joins; and that ORM is an 80/20 solution, in which 80% of users require only 20% of SQL functionality. But I can say that this has not been true. Only at the beginning of a project can you work without using joins or using them in a simplistic way. Then you need to optimize and consolidate queries. Even considering that 80% of users use only 20% of SQL features, 100% will have to violate their abstraction to do what needs to be done.

• The advantages of using ORM disappear with increasing complexity because it is necessary to promote a break in abstraction by forcing the developer to deal with SQL;

• Objects are not an adequate representation of relational queries;

• Instead of using relational databases and ORM as a solution to all problems, if your data is objects by nature use NoSQL;

• OO design can not represent relational data efficiently, this is a fundamental limitation of the OO design that ORM can not handle.

In short: ORM and a shot in the foot from my point of view.

    
16.12.2016 / 19:39
Using unused affect performance? Mask for CPF and CNPJ in the same field