Which ORM is better for my application NHibernate ,EntityFramework or LinqToSql? and why?
-
I want to use one of the 3 ORM options (NHibernate, EntityFramework and LinqToSql) in my application which one is the better? and what is the advantages of it over than others?
I have used both Entity Framework and NHibernate extensively. I would say that if you are using the ASP.NET 5 (ASP.NET CORE) technology then EF7 is a good tool but if you aren't using the cutting edge ASP.NET tech then I prefer NHibernate but EF 6 will work as well. Please note, EF7/ASP.NET 5 (CORE) are not out of beta yet... Like others have pointed out, this also depends on your project. From my recollection, NHiberante has the ability to connect to a lot more data providers so if you need to integrate with MySQL, MsSQL, Oracle, etc. in the same project then NHiberante might be a better choice. Food for though
Eric
-
If I were developing the application, I'd avoid using an ORM altogether. I don't like the lack of fine grained control they present and the fact that they largely constrain me to doing things in certain prescribed ways - as soon as I want to do something out of the ordinary, things become a lot harder. Now, as to your question - only you can answer that. We don't know what your application is, what it does, how it scales, etc. You might as well go to your local swimming baths and say "I want to buy a car. A Mercedes, a Volkswagen or a Ford. Which is better and why?"
This space for rent
I went through the OR/M craze for a few years too before switching back to standard DataLayer models. The biggest issue for us is that ORMs have direct access to tables and generate Non-optimized SQL code that can be difficult to monitor and tune and as soon as you want to do something out of the ordinary, the complexity skyrockets. We have since moved back to the model where all access to data routes through Stored Procedures, which restrict access, creates audit trails, and santitizes input.
-
I want to use one of the 3 ORM options (NHibernate, EntityFramework and LinqToSql) in my application which one is the better? and what is the advantages of it over than others?
What about Dapper?
-
I want to use one of the 3 ORM options (NHibernate, EntityFramework and LinqToSql) in my application which one is the better? and what is the advantages of it over than others?
I'm currently using nHibernate with FluentNHibernate. I like it, for easy queries from tables. Having said that, I'm trying to get rid of it and switch to Dapper. My website has gotten way to complex for nHibernate queries. I have to do anywhere from 3 to 30 SEPARATE calls to the database just to get all of the data for my view model. That's AWFUL, and one of the huge downsides to non-asynchronous ORM's. At my work, we use an ORM-lite, similar to Dapper. It is AWESOME! You write all of the stored procedures to access all database information, it's fully asynchronous, AKA FAST! I recommend something like Dapper.
-
My Application is a an MVC web application
>> My application is a MVC Good question. I don't have an answer, but, I do have the same question. I have only worked with small MVC projects, and most of them, use a "different way of doing things" that an O.R.M. I have read some people have made custom MVC (or MVP, MVVM, etc) and ORM, hybrids, but, dont have a web link right now. I made a custom, N-Tier (3-Tier) and Entity ORM library Hybrid for some customer. I actually wanted to avoid to "reinvent the wheel", and wanted to use either Microsoft Entity Framework or NHibernate, Subsonic or others. For the framework part, Microsoft MVC and MVP didnt exist or was the first version, same thing goes for Linq,and LinqToSQL. MS was changing from VS2005 to VS2008, and the other frameworks (mostly Open Source), where also changing, some where deprecating the VS2005 version, while the changes on the VS2010, didn't have enough documentation, altought I read on the web, at the time, that where good. And, for another reason, the customer need it, the software on MySQL and Firebird (Interbase), not MS SQL Server. Myself, I required to be available on PostgreSQL. The native MS Entity and other existing didnt have finished support for the other databases, at that time, they do now. The paid ORM libraries like Telerik Open Access, and others, cannt be affored by my customer, or myself. So, I ended having to reinvent the wheel. Today, many of my other customers, still have VS2005, VS2008, VS2010, and are not interested to migrate to newer versions. Now, I have two scenarios. For new projects, I need to find a way to use MVC/MVP with other databases that are not MS SQL Server, some of them already support MS Entity, Linq or LinqToSQL, other doesnt. For legacy projects, some of them can be redone, by migrating as new projects, others, I need to find a way to merge to a MVC or MVP framework. I will read the others answers, to see if they can be useful for my software projects. Cheers.
Mark Ramirez mail dot umlcat (a) gee mail dot com
-
I went through the OR/M craze for a few years too before switching back to standard DataLayer models. The biggest issue for us is that ORMs have direct access to tables and generate Non-optimized SQL code that can be difficult to monitor and tune and as soon as you want to do something out of the ordinary, the complexity skyrockets. We have since moved back to the model where all access to data routes through Stored Procedures, which restrict access, creates audit trails, and santitizes input.
-
I went through the OR/M craze for a few years too before switching back to standard DataLayer models. The biggest issue for us is that ORMs have direct access to tables and generate Non-optimized SQL code that can be difficult to monitor and tune and as soon as you want to do something out of the ordinary, the complexity skyrockets. We have since moved back to the model where all access to data routes through Stored Procedures, which restrict access, creates audit trails, and santitizes input.
EntityFramework allows the use of views and stored procedures in place of tables. I use stored procedures for create, update and delete, and use views for retrieve. When I alter a table, it is very simple to update the application from the database. The application itself is just the server side of a web API, which works without my having to specify individual column names, until I get to the actual use of the data in the web client. I will say that I also don't like the sometimes buggy black box that ORM tends to be. I wrote a PHP version of my server application in which all of the tables and column names are specified in one, simple class file, and all of the routing is specified in one other simple file. The code is fairly transparent and, except for those two files, it is unnecessary to make changes to it to adapt to entirely different database structures, but I can easily do so, if necessary. The flexibility of PHP allowed me to do all that an ORM would do without an ORM black box.
-
I have used both Entity Framework and NHibernate extensively. I would say that if you are using the ASP.NET 5 (ASP.NET CORE) technology then EF7 is a good tool but if you aren't using the cutting edge ASP.NET tech then I prefer NHibernate but EF 6 will work as well. Please note, EF7/ASP.NET 5 (CORE) are not out of beta yet... Like others have pointed out, this also depends on your project. From my recollection, NHiberante has the ability to connect to a lot more data providers so if you need to integrate with MySQL, MsSQL, Oracle, etc. in the same project then NHiberante might be a better choice. Food for though
Eric
NHibernate and other (Open Source and Commercial) Libraries are good. I had a case, where I consider to use a very previous version of NHibernate, but, couldn't, due to switching between VS versions, and poor documentation. NHibernate was my first choice, but, have to drop all of them in favor of a custom ORM, which to be honest, was difficult to implement. Wish NHibernate had better documentation and examples at that time...
-
I'm with Pete. What would you actually gain by using any of them? "Use the right tool for the right job." -- Scotty et al. ORMs can be likened to a pneumatic nail gun -- very useful when building a house, not very useful for building a bird house and completely wrong for constructing an electronic circuit. Always consider your application and its needs on its own, don't simply make it match what some other developer did for some other application which may have absolutely no bearing on what your current application needs to do. None of the applications I have ever developed would have benefited from using an ORM, or "entities", or "custom data objects". I doubt even ten percent of the applications out there really benefit from their use.
The benefit is a great reduction in the time required to code a new application.
-
My applications all use stored procedures and queries in which I make full use of joins and variables to do what I need. Linq often makes very simple tasks much simpler, but the strong datatyping of Linq sometimes makes slightly more complicated things impossible to code or impossible to debug, and my code grows tremendously to get what would otherwise be simple things done.
-
My applications all use stored procedures and queries in which I make full use of joins and variables to do what I need. Linq often makes very simple tasks much simpler, but the strong datatyping of Linq sometimes makes slightly more complicated things impossible to code or impossible to debug, and my code grows tremendously to get what would otherwise be simple things done.
-
I went through the OR/M craze for a few years too before switching back to standard DataLayer models. The biggest issue for us is that ORMs have direct access to tables and generate Non-optimized SQL code that can be difficult to monitor and tune and as soon as you want to do something out of the ordinary, the complexity skyrockets. We have since moved back to the model where all access to data routes through Stored Procedures, which restrict access, creates audit trails, and santitizes input.
As an experienced ADO.NET/TSQL developer, it's been my experience on every project that has used EF, headaches and issues have arisen during maintenance and while attempting changes. For years, I thought perhaps it's because EF wasn't properly implemented in the first place. I mean, who doesn't enjoy generated data entity class objects, etc... After readying quite a bit of negativity on using ORM's instead of stored procedures, it's obvious that the opposite of rational knowledge is one's intuition, or gut feeling... Thus, I feel slightly vindicated but should have listened to my instinct all along.. :)
-
I want to use one of the 3 ORM options (NHibernate, EntityFramework and LinqToSql) in my application which one is the better? and what is the advantages of it over than others?
Use the one you "like". I use Entity Framework "Code First" for all my prototyping; big or small. I deal with a lot of XML related services / data imports. With EF and Visual Studio, I can take XML data and definitions, and generate a fully loaded SQL Server databases that can be accessed in any number of ways, including LINQ to Entities, in under 30 minutes. I don't even have to think about whether there is an easier way. The original model can subsequently be expanded upon using partial classes; leaving the original model intact (and simple).
-
The benefit is a great reduction in the time required to code a new application.
For smaller projects, any benefit in code writing time is outweighed by the time taken to learn the ORM. Similarly, I have found, many ORMs (that I have tried) seem to generate over-complex code under the bonnet. I may not last forever but the mess I leave behind certainly will.