We are getting ready to begin redevelopment of a large aging internal enterprise application. We have decided to use ASP.NET MVC, but under consideration is which Object Relational Mapping (ORM) to choose. There are of course a multitude of open source and paid ORM implementations available. However, NHibernate seems to hold the largest mindshare, while the Entity Framework is the new hotness from Microsoft.
While we are doing research and toying around with both we wanted to put it to the community as to which ORM (NHibernate, Entity Framework, or otherwise) they prefer and why.
Somewhat similar Stackoverflow Questions
What are you favorite .NET ORMs? (good list, but w/o justifications)
ASP.NET MVC + ORM (focuses primarily on Castle Project AR)
What object mapper solution would you recommend for .NET? [closed question]
Additional .NET ORM Reading
ORM in .NET 3.5
Why use the Entity Framework?
Why use the Entity Framework? Yeah, why exactly?
Best .NET ORM Tool
You should have a look at Sharp Architecture an ASP.NET MVC application framework which uses NHibernate.
I've used a few O/RMs in the past couple of years and there's no way would chose anything other than NHibernate.
It's the most mature.
It's got a huge set of features.
It's got a good community behind it.
It's got some fantastic ancillary projects such as Fluent NHibernate.
I don't know what more information people will be able to give you over and above in the questions that you have linked to.
Crazy talk answer: none.
This is not to say ORMs are not awesome pieces of technology when used right. But in 2011, they are quickly becoming the universal hammer where not all problems are nails. And there is so much going on in the modern ORMs that, especially for people not well versed in them, they can confuse things more than help things. Or, sometimes things are simple enough that straight SQL is a better alternative. No matter how good the ORM is, the abstraction will leak at some point.
The other side of things to look at is the whole NoSQL movement. The technology is still a bit new, but for new work it is a data access strategy one must consider as it takes so much cruft out of building your application.
Short answer: use both (i do really use both)...
With ORM there are multiple possibilities, all depends what you want.
As a real ORM mapper I strongly recomment NHibernate and Fluent NH mappings. You need a lot of research to put together a nice architecture, but then nothing stands in your way. With minimal compromises you get real flexibility.
EF6x (core is not prod.-ready IMHO) is called an ORM, but what it generates is more closer to a DAL. There are some thing's you can't do effectively with EF6. Still, this is my favorite tool for a read-model, while I do combine it with NHibernate (where NH I use for a DDD/write model).
Now to performance - its always pro and cons. If you deep deeper into ORM architecture (see my article: avoid ORM bad habits) then you will find intuitively the ways to make it faster. Here's my another article on how to make EF6x 5x faster (at least for read situations): EF6.x 5x faster
Related
I am building a web api for my application and right now i am looking for ways to design my data access layer.
At the end, the application should be able to support a very large number of client and a very large number of queries.
I have heard about entity framework but i have two concerns with it:
I have been told by many that entity framework is not the best when it comes to performance, and performance is something that i can't afford to neglect.
I am only starting to build the application and i'm still looking for developers to join me, if i start with entity framework now, i might want/need to change an orm/library (because of the reason above or any other reason) or even a database technology in the future.
Repositories are a great way to abstract the data access layer and make it invisible to the business layer, so if one day i want to change the DAL/Database technology, i won't have to touch the business, only change the repositories.
Still, i have read a lot about how combining entity framework with the repository pattern is a bad practice.
I am really confused... and i have few questions.
Should i use entity framework? Performances is an important thing to me.
Should i combine it with repository pattern? If not, what do i do when i want to change the database technology/orm?
I have practice with using the repository pattern with native sql client (running native sql queries) but i don't have any practice with using orm's, at least not in .net
Is it really a bad thing for big application to use native sql queries and wrap them with repositories?
It is really important for me to begin writing my application in best way possible (applying all the best practices) so i won't have much struggle in the future.
Thanks,
Arik
Ad.1) Yes, Entity Framework is dead slow - BUT - when used out of the box, if the developers has deep knowledge of Entity Framework, what it does behind the scenes, how to optimize the queries - it can be as fast as your more low-lewel own implementation of data access.
Ad.2) If you want to change the ORM or the Database technology - that is not a matter whetever you use EF or not, it's a matter of the architecture you will design for the software.
Ad.1) see former Add.1, if performance is really important, I personally would go with low-level SqlDataReader, altough as I sad, it's possible to use EF in a performant way.
Ad.2) I don't see nothing bad in combining the repository pattern with EF, in small applications it may be an overhead, because the EF is basically an implementation of an repository pattern, so you would get a "double repository pattern", but it allows you to abstract away the coupling with EF
Ad.3) I don't think it's a bad way - but it depends obviously on the application.
I think that using a repository pattern is a good idea and a sort of wayout if you have some performance issues.
About Dapper the question is why Dapper is more performant than EF and NHibernate. No Lazy Load, no DML, easy mapper and so on. If you want DML (I do) and sometimes Lazy Load you could have a mixed approach. Repository Pattern + EF + Dapper.
My approach actually is Repository Pattern + EF + very few query (massive update and delete and few select - EF writes huge SQL statements also for simple queries - ). To map the select you can include Dapper (I don't), do it by hand (manually mapping or use the features inside EF - but there are some limitations - or write something generic). Usually I map it manually but I wrote also a mapper based on EF Mapping
Entity framework Code First - configure mapping for SqlQuery
I used it for few times and actually I don't use it anymore.
I have read some articles about automatic code generation of ADO.Net data access layers in .Net applications. There are some tools available like CodeSmith or LLBLGen Pro. Does anyone has experience with these tools? Is it better to use these tools rather than using LINQ? Thanks.
Better is subjective - however, I understand what you're really trying to ask. Essentially, my answer to the question of which tool is right (best) for the job is: it depends on the job. Linq -> SQL is older tech of which M$ has no plans of updating or improving. I would stay away from it... if you want similar functionality Entity Framework or another ORM is best.
NoSQL is huge right now and offers a big boost in productivity due to no database development or mapping or ORM layer to muck with. Just create your entities and store them! My recommendations on those are:
RavenDB
CouchBase
MongoDB
Riak
Redis
Cassandra
There are also graph databases useful for 'networks' of 'things' that are related in some fashion or another.... the two that I've used are below:
Neo4j (popular, java based, has .net client)
Sones (.net based - newer kid on the block)
As for SQL databases - well, some companies don't want to endure a paradigm shift or have requirements that stipulate only x database will be used in the company, etc... In those cases you have to work with whatever you have to work with. ORMs can aid in this arena... Some popular ORMs are listed below:
Entity Framework (M$)
NHibernate (very popular)
Subsonic (older but still used)
Dapper
Massive
PetaPOCO
And as for regular ado.net and to address your main question - there are not a lot of frameworks that generate the data layer for plain ado.net, etc... but I did find these and it turns out to be very useful in my projects:
http://www.elencysolutions.co.uk/ (not open source)
http://spgen.codeplex.com/ (open source & customizable)
http://www.nettiers.com/ (open source but sorta old-erish)
We are a small team working on a very tight deadline to develop a large web application in .NET. We are using multiple databases (one per client) so our requirements are slightly different than most applications. The databases will only be used for this particular application so it doesn't matter if they are tightly coupled with the application. The main deciding factors are speed of development, long-term maintainability, and security. There are 3 options we are considering:
Option 1 - LINQ to SQL
None of us have any experience with LINQ, but we have been researching it and it seems like a good option and not too difficult to learn. Worth the risk of learning a new method on a tight deadline?
Option 2 - Stored Procedures
Seems like it could be a nightmare to maintain with the multiple database setup (or would it?) and it may slow down development to work in another environment as we don't have a dedicated database developer. Basic CRUD queries would be generated by code generator which is an advantage.
Option 3 - Inline Queries
This method would be the fastest to develop but I know people are generally against hard-coded queries nowadays and I fear we may suffer in the long term with maintainability issues. Basic CRUD queries would be generated by code generator.
Please let me know if there are any factors we are missing. What solution seems the most appropriate for this project?
If you have a tight deadline don't try something new. Ask the devs to study Entity Framework at home and in their spare time and try it in next project. Meanwhile do what you know best and have used in past successfully.
Inline queries are not bad if they are decoupled in a DAL assembly.
Since #Hasan Khan covered the primary answers regarding SQL. I'm going to throw out a somewhat different answer. Another option is to consider usage of RavenDB, a NoSQL db. It has the concept of Tenant databases inherently baked into it. Which from your requirements it sounds like this is the intended goal.
Which orm you would recommend for a beginner moving from ado.net?... Thus far used ado.net stored procedures with asp.net and now like to move with an orm.. Any suggestion..
NHibernate is nice, but it does require a bit more configuration for the ORM (even though fluent NHhibernate is quite nice).
I have heard that beginners in .NET ORM's have had quite good success with Subsonic: http://www.subsonicproject.com/.
NHibernate. The new development branch - much better support for LINQ than the current released versions.
At the risk of sounding odd - why not http://msdn.microsoft.com/en-us/library/bb425822.aspx??
Yes, I know - Microsoft has officially said there wouldn't be much more development on it - even though it was bugfixed and enhanced in .NET 4. It's still in .NET 4 - so it'll be around for at least 3-5 years. It's easy to use - much easier than NHibernate - with a visual designer and code generation.
It's simple and easy to understand, and it can give you a great intro to using an ORM.
Once you've learned, internalized, and understood the principles, you can always move on to a more enterprise-ready solution, like NHibernate, or Entity Framework v4.
See Scott Guthrie's excellent blog post series on Using Linq-to-SQL for a great intro, or check out the Nerddinner tutorial which showcases ASP.NET MVC and Linq-to-SQL.
NHibernate is currently one of the most popular ORM's, but Microsoft has been busy working on Entity framework. In time this may become the most popular and the best simply because it comes with .Net Framework.
I'd second the LINQ2SQL option if you're using SQL Server.
LINQ2SQL:
is easy to learn, with lots of guidance available online;
has good tooling for design and debugging in Visual Studio; and
provides adequate performance for all but the most extreme of situations (StackOverflow uses it for data access, for example).
There have been rumours of its demise for a while, but Microsoft's market research seems to show more developer support than for Entity Framework which, whilst arguably more powerful, is also more complex. LINQ skills are transferable to other ORMs too, with options for LINQ2Entities (for Entity Framework) and, I believe, support from SubSonic also.
Entity Framework
Definitely try that out. Solid support from Microsoft themselves, support for Many-to-Many relationships, eSQL lets you at the lower layers, etc.
I am tasked to build a web 2.0 style mashup application which consumes a lot of 3rd party webservices like youtube and twitter. There are also lots custom features which are going to be built using ASP.NET 3.5 and SQL Server 2008. Now I am looking for the right ORM for my needs. From a performance and ease of use standpoint can anyone suggest me the right ORM for this kind of web application?
From a perform perspective, only a very poorly crafted ORM will be your bottleneck. The database or network traffic to and from the database are much more likely to be a performance bottleneck. It's not really necessary to weigh performance when choosing an ORM. While it is straight-forward to create simplistic ORM performance comparisons, it's much more difficult to create real world ORM performance comparisons, but you are welcome to try.
ORMs also aren't built for "ease of use". They are built to hide the object/relational mismatch. The major ORMs all do an adequate job of hiding the object/relational mismatch. Ease of use is fairly standard across the board, except where feature sets differ.
The biggest difference between the major ORMs is feature set. Some have very few features while others have a lot of features. Cost can also be a differentiator, although there are plenty of "free" alternatives that are decent.
For .NET 3.5, NHibernate is clearly the best option in the large majority of scenarios. LinqToSql is feature poor, and Entity Framework 1.0 / 3.5 has been widely panned for making some very poor design tradeoffs while rushing the product to market. There are other adequate .NET ORMs as well, but again, they don't compete effectively with NHibernate in the majority of scenarios.
A lot more opinions about .NET ORMs can be found linked from this question:
NHibernate, Entity Framework, active records or linq2sql