Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am just switching from C to C# and would like to invest sometime learning database work. I am overwhelmed with the options: Linq-to-sql, ADO.NET. nHibernate, EntityFramework, plain old sql (I am used to this). Since I have only limited 'learning' hours available (about 2.5 hours per day), where should I invest my time?
I don't want to learn something that will be obsolete next month or for which no one will hire me.
If I learn EF, will this knowledge be easily transferrable to nHibernate?
Update: I decided to start with nHibernate. While EF 4.0 has fixed many shortcomings, I don't have VS2010 right now and won;t have it for another 1 year. So nHibernate is the man for now.
Personally, I think NHibernate (plus FluentNHibernate and Linq to NHibernate) lets me keep the most sanity. In real world projects, managing a single EDMX file for a large data model in Entity Framework is really painful across a large team; in NHibernate, Fluent lets you separate things across multiple C# files, or the HBM xml format allows you do use multiple XML files. The last time I used the Entity Framework, that wasn't easy unless you had separate DataContexts for each model. (If that's changed in some way recently, I apologize for my ignorance). The most difficult thing about NHibernate will probably bite you in most ORM tools in one way or another: mapping object graphs to relational models is tricky. But you get an awful lot of control over things like lazy loading, parent/child relationships, and so on; mapping by convention is also a huge win if you're using Fluent.
But you won't go broke picking the tool that Microsoft is investing in; a lot of companies didn't even seriously consider using an ORM until the Entity Framework was released. Personally, I don't really want to work for companies that defer decisions like this until their vendor finds a passable solution, but the fact is, a lot of companies do (or will) use the Entity Framework.
There's absolutely nothing wrong with using the Entity Framework, although I suspect that if you used EF in anger for a real-world project for 4 weeks, and NHibernate in anger for about 4 weeks, with multiple developers on the project, there's a good chance you'd find NHibernate simpler. In my experience, EF looks much simpler at first, but gets hairier the longer you use it. NHibernate looks and feels much harder at first, but gets simpler and more obvious the longer you use it.
Rather than pick something you think you might be hired for, focus on EF (perhaps) as a concrete example of a solution to the ORM problem as a whole. In spite of leaning EF your future employer might be an nHibernate house, or have their own home-grown solution. Learn EF, but use that experience to learn the ins and outs of ORM.
EntityFramework is what Microsoft is showing as their proposed database technology. It incorpates a lot of what Linq-to-Sql does. I would start there along with ADO.NET. You'll encounter ADO.NET a lot as well.
Like the comment says too Linq-to-sql isn't being advanced anymore either.
http://msdn.microsoft.com/en-us/library/aa697427(VS.80).aspx#ado.netenfrmovw_topic2
If you wish to explore Entity Framework, this series of Pluralsight videos by Julie Lerman demonstrates many of the basics you'll need to get going. As Kevin mentioned, Microsoft is putting less emphasis on LINQ-to-SQL and more on LINQ-to-EF.
NHibernate has greater flexibility in inheritance mapping, better integration with stored procs / database functions / custom SQL / triggers, support for formula properties and it just a more mature platform than EF 4.
(sorry for the long post ahead, but I decided to try to give a bit of background to two of the main frameworks)
I'd like to add that using a non-Microsoft technology has the advantage of creating a larger birds-eye view of the problem and prevents you from locking yourself into that .NET + Entity + SQL Server cycle (even though Entity is database agnostic).
You might consider NHibernate. It's arguably one of the most mature open source ORM frameworks available. It is fast and it is used by large and very large enterprises. There also lies its greatest weakness: NHibernate is considered to have a rather steep learning curve. If you take this path, I can recommend the excellent book "NHibernate In Action" published by Manning.
Many of the weak points of NHibernate have been taken away from two sides: best practice ORM enterprise have been implemented in the S#arp architecture (downloads at Github now), which also covers fully automated mapping from database to MVC architecture. S#arp Architecture makes complex NHibernate scenario's a breeze (but still has a steep learning curve).
On the other side is the easy-configuration part through Fluent NHibernate, which creates a "one point of maintenance" situation: just code your entity objects in C#, call Config and the database is created if it doesn't exist. Saves you a hell of a lot of time. Fluent really makes working with NHibernate as it always should've been (and actually, as EF could've been).
Note that, unless it has changed recently, that Entity Framework requires changes to the database for the stored procedures, which is why I personally rarely applied it. Also, EF does not scale too well in enterprises unless you add a lot of effort yourself. NHibernate shines when you have an existing database, need it for large enterprises, or do not want to change what you've already created (incl. triggers, SP's, constraints).
From a learning perspective: as others have said, learning EF is a good start, it is rather easy and there's ample documentation. Smaller organizations are more likely to use EF because of the ease-of-use. Medium sized to large companies are more likely to go to NHibernate (and comparable enterprise-minded mapping systems). EF is rather new, NHibernate has a long history. Both have their merits. Both work well with LINQ. Both are (very) good to understand well and find a place on your CV.
I'm in the same boat as you, I found the Summer of NHibernate series really useful.
http://summerofnhibernate.com/
Thanks
-Hem
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 months ago.
Improve this question
Please consider these assumptions:
I have a high traffic web application with millions records in database tables.
Suppose I know enough about EF and how to properly use it in its optimal way.
I prefer to use EF in my applications due to its compatibility with OOP and ease of use.
I know EF (even with best practice usages) has some performance downsides in compare with Dapper or ADO.NET.
But my question is that based on my assumptions, is this performance issue considerable or I can use EF safely in my high traffic web application?
I have a high-traffic web application with millions records in database tables.
No one (mostly not the database) cares about millions of records unless you forget to put indices on it. Way more interesting is how complex the queries are. Most queries - particularly those that can use an index at least to reduce the numbers parsed - are trivial load on billions of records, but a join over 15 tables hat forces 100gb of data into tempdb is a problem.
I know enough about EF and how to properly use it in its most optimize way.
I doubt that, particularly for EF Core which seems to change every weekend. But ok, you do avoid the most stupid things, like one dbcontext for the whole application.
I know EF even with best practice usages has some performance downsides in compare with Dapper or ADO.
This is so totally not true. The point is more - EF does a lot that neither Dapper nor ADO directly do, and this comes with a price. This is like "A Ferrari is faster than a truck, but there are downsides".
The truck is slow - except if you transport a lot of stuff. I.e. queries come with a lot of overhead - but if you do not care about ever updating the data you query (typical in web applications), then turn off change tracking for this query. Getting objects has an overhead - ok, happens.
But you can filter which properties you materialize. Do it and the amount of data goes down. EF is not exactly super fast - but it is not exactly awful either. Dapper and ADO(.NET) beat it, but they do less.
In fact, EF is built on top of ADO.NET, because unless you plan to write the whole network stack yourself, ADO.NET is the only way to talk to most databases.
The whole problem is: what do you think is high traffic? I have seen EF successfully deployed in applications with tens of thousands of parallel users. I have then made some critical functions 100 times faster because the pro programmers knew everything about EF - but no one taught them how to put the proper indices on tables.
EF is perfectly capable on large applications, but depending on usage you may have to scale to some servers, unless you write very efficient user level code and avoid inefficient things like enumerating all values and then filtering in memory (and yes, I have seen this - particularly with "we do repositories around EF" people that then thought returning an IEnumerable is a good idea).
There is nothing in EF that will inhibit your application's scalability. If there is a performance difference, you can compensate with additional resources. And you can manage the tradeoff between resource cost and development cost on a case-by-case basis, rather than making an up-front Architecture Decision.
And an EF application with selected performance-critical transactions implemented in ADO.NET and/or Stored Procedures is typically not materially slower or more expensive to run than an application written entirely with ADO.NET and Stored Procedures.
As long as you're aware of best practices, and beware of absolute "DO NOT"s, yes it is. There always will be developers who don't know what they're doing and joins a List<> object into a Linq query which will result fetching all records on that table. There always be another who joins or includes all relations when it is not necessary. And another who fetches the entity with all of its fields when the code actually needs one field from that entity.
We're using entity framework core in a big government project, having hundreds of millions data in many tables and having hundreds of requests per second in a work day. As long as you also optimize table indexes and relationships correctly, it's all fine. It's not about the library, it is about whether you use it wisely or not.
Dapper encourages to write plain SQL and thus you can have more control if you are a SQL expert; you can write complex queries the way you like. It is still faster than EF core. There are certain verbosity with EF core using code-first. For instance for composite foreign key you have to override OnModelCreating and specify the rules. Further to specify different table-names other than the model you have to write code for it. If you happen to make changes in the Migration table(which usually happens during testing) then you might have to do the subsequent commits (for model changes) manually in the database after generating the scripts and analyzing the difference visually.
The question is "Do we have to think of ways to optimize Dapper?" Then answer is "No, it is by default optimized".
Another question is "Do we have to think of ways to optimize EF core?" Then answer is "Yes, you have to take lot of things into consideration".
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am currently exploring of using Entity framework for the windows based (forms) application I'm developing that does data mining for a dataset of more than 1 million rows (my datasources are from oracle, sql server, sqlite). What the application will do is I parse these information to the users local client, and I utilize linq to objects in mining useful information. The said application shall only read information to the source database as its output is written in an excel file.
Given the significant ease of using the Entity Framework in terms of reducing the development time (this is the first time I will be using an ORM, and coding the necessary dataaccess objects takes about 80% of my time based on the previous projects I've done before), I would like to ask if it's worth it to use EntityFramework to the application I'm working in? How much would be the performance drop (as compared to using DataReaders) when reading tables for over 1 Million rows?
Also, given that I'm new to this technology, I would much appreciate it if you could refer me to useful tutorials and best practices.
Using pure ADO.NET will give you practically best performance you could get. But bear in mind that after you fetch data from data source, you would still need to map results to your object model (something that is done by EF automatically) so that you can perform actual data mining.
Mapping could be tough or easy process to do depending on how complex your data model is. For example, Entity Framework is good at mapping hierarchical data structures, which is useful when fetching related entities (or even their related entities) along with the actual entity.
You should also consider how often does your data model changes (and how big those changes are), so you calculate maintainability cost too. Having tons of SQL that you have to change every time you add new column is another point of getting problems. In this case, maintaining EF model with POCO's would be easier and more convenient.
Note that there are other O/RMs that can give you kind of best of two worlds (performance of DataReader and easy mapping to POCOs of Entity Framework). Among these are: NPoco (former PetaPoco), Dapper (the one used at StackOverflow), NHibernate (using HQL can be quite fast), OrmLite (has basic LINQ-like queries support) and many others.
Take a look at Dapper's performance benchmarks results that might give you some picture of what performance can be achieved with popular O/RMs.
Performance of either technology of fetching data is really dependent on what data model you have in the database.
That's why it's important not only to analyze existing benchmarks, but also perform your own based on your particular use cases on your data model. As a starting point, you can grab Dapper's performance tests code and tweak it according to your needs (data model, typical queries, etc), so that you get more comprehensive and realistic performance results using different frameworks.
EF is never as fast as using raw ADO.NET with an OracleCommand. After all, EF is another layer on top of ADO.NET; it's main goal is to provide programmers with convenience features of mapping raw columns into fields and rows into objects.
If you need the absolute top-notch performance, then you need to use raw ADO.NET. The downside of this is the fact that you need to start fiddling around with untyped rows and columns.
There ain't no free lunch - either you have top performance but an unpleasant programming API, or you get convenience and productivity - at a performance price.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have just started learning asp .net web forms, I do have knowledge of web development as have done few todolist and blog type pet projects with php and have created simple CRUD in CodeIgniter. I was wondering what to learn and what will be easy for a beginner to grasp Linq to SQL or entity framework ?
I wanted to learn faster and create something that I have in my mind as STARTUP project. I only have 1 month to learn Database layer and only 15 days to at-least master basic CRUD of .net rest one moth will be spent on learning asp's stuff and AJAX.
Few are suggesting me to first learn ADO.net ?
Maybe I'm completely messed about these technologies because of my lack of knowledge in .net field.
First of all, it's worth noting that there are three approaches that can be taken with Entity Framework:
Model First
Code First
Database First
While I may be incorrect in this assumption, my experience has been that Model First has lost quite a bit of popularity, thus boiling down to just two options. That said, the fact that there is more than one way to "skin the Entity Framework Cat" means that you are adding to its inherent complexity.
Second of all, Entity Framework is incredibly powerful. It is a true ORM with incredibly flexibility and power...IF you know how to use it.
Which is more difficult to learn? Probably Entity Framework. That said, you're not in the business of learning what is easier, you're in the business of learning solutions for the given problem. If you're going to pick up an ORM, I'd rather learn the option that is considered the mainstay of the category.
If you want something that is less complex in terms of features, but requires more hands-on sql, consider learning Dapper. It is quite impressive...as a Micro ORM.
And finally, there is very little reason for you NOT to learn .NET MVC over Webforms. That's where the work is going. Prioritize learning the technologies that will advance your career. You'll be grateful that you put in the effort in the long run.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Me and my team are going to start a new Project and we are at the stage of exploring and testing some new (or not so new) technologies.
Till today we were using classic ADO with DBDataReaders, proxies for lazy loading and in some cases DataTables.
The team consists of 3 developers and one Database designer.
Our projects consists at least 130 tables each.
Our new project has the potential to grow so we expect 100 tables for sure.
I have been reading and doing some simple testing with EF5 the last 2 days and i still can't decide if we should use it.
We usually split a big Project into many "module" projects allowing us to work faster and better under source control. Are we going to use one big "edmx" for the whole DB?
Since we have a Database Designer i suspect that CodeFirst is not an option.. So is it worth to use EF with the Database First approach?
If we use the Database first approach is the EF smart enough to detect all the relationships correctly and be ready for usage with no more additional configuration by me? (By extra configurations i mean i will have to write DataAnnotations or have to ovveride the DbContext)
Personally i find my self very confident about designing a Database with sql. The only annoyance i have is when i have to update all of the select, delete, update, insert scripts when an entity is changed in my classes-Lists.
EF will take care this for me but except this i'm starting to believe that it will slow down the performance and eventually slow down my production since we are not familiar with it..
What do you think IS IT WORTH IT ?
*Except the DataAnnotations and the DbContext ovveride, is anyone using plain T4 templates to create the tables(schema)?
I'd absolutely recommend to create multiple models. You can select which tables, views, and stored procedures to map for each.
Database first is absolutely fine.
If the database constraints have been set then EF will recognize them. You won't get around minor modifications, but all in all EF does a pretty good job.
Using EF will have a slight impact on query performance. But in most cases that won't be an issue. In the few cases where you may have an unacceptable performance hit, you can optimize by injecting your own SQL into EF where necessary.
I think, you'll become familiar with the usage of EF pretty quickly, therefore I don't think unfamiliarity will be an issue for long.
I decided not to use the EF.
I am not going to take the risk of using it in a big project.
All the work needed to use it, the possibility of dealing with bugs, the extra overhead..
I prefer writing more sql code and spend more time maintaining, than dealing with the generated models or checking the sql profiler for the generated queries..
Thank you all for your comments..
*Before i go to straight ADO again i will give a shot to FluentData and Dapper..
I will open a new question so if you guys wanna comment on these two light ORMs, i will post the link later.
If your database structure is mature, EF should be a good solution for you.
If the database structure is being developed, or will change alot over time, I would assert that EF may not be the best for you.
EF needs to be refreshed when there are structural changes (and potentially interface changes at the database layer). You should consider how you will manage database changes within your already developed code base.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
If starting a new project what would you use for your ORM NHibernate or LINQ and why. What are the pros and cons of each.
edit: LINQ to SQL not just LINQ (thanks #Jon Limjap)
I have asked myself a very similar question except that instead of NHibernate I was thinking about WilsonORM which I have consider pretty nice.
It seems to me that there are many important differences.
LINQ:
is not a complete ORM tool (you can get there with some additional libraries like the latest Entity framework - I personally consider the architecture of this latest technology from MS to be about 10 years old when compared with other ORM frameworks)
is primarily querying "language" supporting intellisense (compiler will check the syntax of your query)
is primarily used with Microsoft SQL Server
is closed source
NHibernate:
is ORM tool
has pretty limited querying language without intellisense
can be used with almost any DBMS for which you have a DB provider
is open source
It really depends. If you develop a Rich (Windows) desktop application where you need to construct objects, work with them and at the end persist their changes, then I would recommend ORM framework like NHibernate.
If you develop a Web application that usually just query data and only occasionally writes some data back to the DB then I would recommend good querying language like Linq.
So as always, it depends. :-)
Errr... there's LINQ for NHibernate.
Perhaps what you mean is which to use:
LINQ to SQL
NHibernate
I prefer NHibernate.
LINQ to SQL is fairly lightweight, but it's a little bit more tightly coupled to your data structure, as opposed to NHibernate which is pretty flexible in terms of the types of object definitions that can be mapped to your table structures.
Of course that's not to say that LINQ to SQL has no uses: this very website uses it. I believe that it's quite useful to get up and running in small applications where the database schema is not as massive.
Start with NHibernate is a bad idea. It shows a good performance only with ably settings. Try to use EFv4 for large projects and L2S (maybe 3rd-part products) for small and medium size. These products are more convenient and flexible than NHibernate and allow you to start quickly.
not a complete list
LinqToSQL
Pro:
better tool support
good linq provider
easy to start with when db-schema == classes -
Con:
not flexible (ie db-schema != classes)
only supports MS SQL Server
no cascading (save, update ... doesnt cascade to referenced objects)
NHibernate
Pro:
a lot rdbms supported ootb
feature rich
very flexible for almost all corner cases
open source
Con:
not so easy to start with
not from MS
there are many tools, but you have to search for
Between the 2 ORMs
i would choose LinqToSql if:
db-schema == classes
only ever use MS SQL Server
shop only allows MS-Products
i would choose Nhibernate if:
richer objectmodel
legacy db-schema
DB other than MS SQL Server or support multiple
performance critical (i think NH has more features to optimise performance than LinqToSql)
NOTE: this is my personal view. I deal mostly with (crazy) legacy dbs and complex ETL jobs where the object model helps a lot over SQL.
I don't use (or even know) NHibernate, I just want to give my testimony: I use LINQ to SQL since about 2 years with MySQL and PostgreSQL databases (using DbLinq on Windows, using Mono on Linux and Mac OS X).
So LINQ to SQL is NOT limited to Microsoft products.
I can confirm that LINQ to SQL is very well suited for small and medium projects, or large projects where you have the absolute control of the database structure.
As the reviews indicate, LINQ to SQL has some limitations that make it an inappropriate tool when there is no direct mapping between the database tables and the entity classes.
Note : LINQ to SQL doesn't support many-to-many relationships (but this can be easily achieved with a few code lines).
The main drawback of NHibernate is the inability to make use of method calls. They cannot be translated to SQL. To circumvent that, you have to recreate expression trees which is difficult to do.