locked
Is entity framework a must? RRS feed

  • Question

  • User283528319 posted

    EDIT

    Before you read the message below you should know, After 1 month of hard try I solved the EF and now I am just wondering why did I hate it? And why did it take too much for me to learn while it is really <g class="gr_ gr_451 gr-alert gr_gramm gr_inline_cards gr_run_anim Punctuation multiReplace" id="451" data-gr-id="451">easy.</g>

    I love it. It gives you lots of lots of independencies...

    Hi,

    I am a long time desktop app programmer with Delphi and MySQL.

    I like them both and I like SQL.

    However, I will be fully honest, I hate entity framework. It is neither SQL nor something else. It is just confusing.

    Could you tell me who the haven created this framework and why?

    Believe me, if I weren't afraid of SQL injection and other kinds of hack or something I would use ADO net with SQL.

    Any help would be appreciated.

    Wednesday, January 16, 2019 1:09 PM

Answers

  • User-887854963 posted

    Hi fatihbarut,

    So a few thoughts on your thread and its questions.

    "However, I will be fully honest, I hate entity framework. It is neither SQL nor something else. It is just confusing."

    Sorry to hear you're frustrated with the framework. There's no reason to hate it though, why not ask for help with the confusing parts, it could lead to the framework being improved for everyone. Once you learn it you might even love it. Also you're right, it's not SQL, it's an ORM mapped to LINQ (https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/linq/).

    "Could you tell me who the haven created this framework and why?"

    Looks like an official Microsoft Project according to it's GitHub Repo (https://github.com/aspnet/EntityFrameworkCore). You can see a list of its contributors at https://github.com/aspnet/EntityFrameworkCore/graphs/contributors they all worked together to make it possible. Be considerate though, many of these people donated their free time to make this possible.

    "Believe me, if I weren't afraid of SQL injection and other kinds of hack or something I would use ADO net with SQL."

    Even with an ORM like EntityFramework, you still need to follow best practices and validate / sanitize user input (The ORM may be able to do some or all of this for you, read the docs). Using an ORM doesn't necessarily mean you're immune to SQL Injection, be careful, mistakes can still happen.

    "Any help would be appreciated."

    Happy to help :)

    On last thing, sometimes reading all the docs can be an overwhelming task. While it's not free (unless your organization pays for you), Lynda provides 1000s of courses on C#, ASP.NET (core) stuff, including courses on LINQ and EntityFramework Core.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Saturday, January 19, 2019 9:03 PM

All replies

  • User-821857111 posted

    You don't have to use EF. It is an option if you prefer to work with data in a strongly typed manner, instead of using DataRecords via DataReaders or DataTables. Feel free to use ADO.NET if you prefer that. 

    Or you could look at Dapper (https://github.com/StackExchange/Dapper). It allows you to write your own SQL, but will take care of mapping the results to entities that you define so that you can work with List<Product> in your application instead of dt.Columns[0]["ProductId"] etc. 

    fatihbarut

    I am a long time desktop app programmer with Delphi

    Yep - I know a few of those. You issues with transferring across to web development and the MS stack are not unique.

    Believe me, if I weren't afraid of SQL injection and other kinds of hack or something I would use ADO net with SQL.

    You can avoid SQL injection in ADO.NET by using parameters in your SQL. Dapper supports the use of them too.

    Wednesday, January 16, 2019 1:45 PM
  • User283528319 posted

    You don't have to use EF. 

    Really am I? where ever I look I see Ef. It is kinda industry <g class="gr_ gr_162 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" id="162" data-gr-id="162">standart</g> and I <g class="gr_ gr_190 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" id="190" data-gr-id="190">dont</g> want to be far away from industry <g class="gr_ gr_301 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" id="301" data-gr-id="301">standart</g>. 

    <g class="gr_ gr_340 gr-alert gr_gramm gr_inline_cards gr_run_anim Punctuation only-ins replaceWithoutSep" id="340" data-gr-id="340">However</g> there should be an easy way<g class="gr_ gr_352 gr-alert gr_gramm gr_inline_cards gr_run_anim Punctuation multiReplace" id="352" data-gr-id="352">....</g> If something is complex it is evil. 

    Everything must have understandable complexity.

    Wednesday, January 16, 2019 1:51 PM
  • User-821857111 posted

    where ever I look I see Ef. It is kinda industry standart

    Yes, it is the recommended data access technology when working with MS frameworks. 

    However there should be an easy way.... If something is complex it is evil. 
    You haven't said what version you are using, but EF 6 certainly has its peculiarities. EF Core on the other hand is a lot more logical to work with. They learned a lot from the issues that they had with adding features to EF 6 and previous versions.

    https://www.learnentityframeworkcore.com/

    Wednesday, January 16, 2019 1:58 PM
  • User283528319 posted

    It is unbelievable. EF is shown 10 times slower than (<g class="gr_ gr_11 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" id="11" data-gr-id="11">forexample</g> dapper) or ADO net. (Edit: in new <g class="gr_ gr_13 gr-alert gr_gramm gr_inline_cards gr_run_anim Punctuation only-ins replaceWithoutSep" id="13" data-gr-id="13">posts</g> they look similar, but dapper still a little bit faster)

    While <g class="gr_ gr_12 gr-alert gr_gramm gr_inline_cards gr_run_anim Grammar only-ins replaceWithoutSep" id="12" data-gr-id="12">situation</g> is like this. Who is still using it?

    P.S: I use <g class="gr_ gr_9 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" id="9" data-gr-id="9"><g class="gr_ gr_10 gr-alert gr_gramm gr_inline_cards gr_run_anim Grammar only-ins replaceWithoutSep" id="10" data-gr-id="10">mvc</g></g> core for my project.

    Wednesday, January 16, 2019 2:11 PM
  • User475983607 posted

    It is unbelievable. EF is shown 10 times slower than (forexample dapper) or ADO net. (Edit: in new posts they look similar, but still dapper still a little bit faster)

    While situation is like this. Who is still using it?

    Developers that write business applications using the .NET stack tend to use EF.   EF is probably not the best choice for landing a rover on Mars.

    Wednesday, January 16, 2019 3:41 PM
  • User-821857111 posted

    It is unbelievable. EF is shown 10 times slower than (forexample dapper) or ADO net.
    Yes. EF does a lot more than Dapper, so the overhead is greater. Most of the time, for most projects, EF's performance is more than adequate. The e.g. 10x speed difference may not even be discernible to the user.

    However, you don't use EF if ultra-high performance is an application-critical requirement. That's why the team at Stackoverflow developed Dapper. Also, EF gives you the ability to drop down to raw SQL if the generated SQL is not to your liking, or what you want to do can't easily be express in LINQ: https://www.learnentityframeworkcore.com/raw-sql. And there is nothing to stop you using a combination of data access technologies/approaches in the same project. I often do.

    Wednesday, January 16, 2019 4:07 PM
  • User283528319 posted

    fatihbarut

    It is unbelievable. EF is shown 10 times slower than (forexample dapper) or ADO net.

    Yes. EF does a lot more than Dapper, so the overhead is greater. Most of the time, for most projects, EF's performance is more than adequate. The e.g. 10x speed difference may not even be discernible to the user.

    However, you don't use EF if ultra-high performance is an application-critical requirement. That's why the team at Stackoverflow developed Dapper. Also, EF gives you the ability to drop down to raw SQL if the generated SQL is not to your liking, or what you want to do can't easily be express in LINQ: https://www.learnentityframeworkcore.com/raw-sql. And there is nothing to stop you using a combination of data access technologies/approaches in the same project. I often do.

    A concern stops me -whisper to my ear- "What if dapper guys decide to stop the project in future? What will happen to your project?

    Wednesday, January 16, 2019 4:49 PM
  • User1520731567 posted

    Hi fatihbarut,

    Is entity framework a must?

    It is not necessary.Depends on what you want.

    EF's advantage is to save time and not write bunch of Data layer code.

    We know that EF is called ADO.NET EF which means that EF sits on top of the ADO.NET ,which tells us that it cant be faster than ADO.NET.

    But remember the power of LINQ which EF provides the developers.

    It is really powerful when comes with EF. Since EF encapsulates ADO.NET at the background it used ADO.NET only, but the question comes why EF then??

    Yes if we use EF and LINQ then the maintainability and code redundancy reduces as we do not have to write the big queries anymore like SP and all.

    Best Regards.

    Yuki Tao

    Thursday, January 17, 2019 6:13 AM
  • User283528319 posted

    But remember the power of LINQ which EF provides the developers.

    It is really powerful when comes with EF. Since EF encapsulates ADO.NET at the background it used ADO.NET only, but the question comes why EF then??

    thanks. Could you explain <g class="gr_ gr_97 gr-alert gr_gramm gr_inline_cards gr_run_anim Grammar only-ins replaceWithoutSep" id="97" data-gr-id="97">little</g> bit more about the <g class="gr_ gr_138 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" id="138" data-gr-id="138">powerfullness</g> of the LINQ?

    And what does EF with LINQ means? Can EF be without LINQ? 

    Thursday, January 17, 2019 6:21 AM
  • User-821857111 posted

    Can EF be without LINQ? 
    No. Every ORM needs a way to express queries. EF relies on LINQ (https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/linq/). 

    Thursday, January 17, 2019 8:58 AM
  • User753101303 posted

    Hi,

    EF is to expose directly your db data as lists of strongly typed .NET objects (rather than going through explicit db reading objects)

    Linq allows to query multiple sources of data using C#.  When using "LINQ to EF", the C# query is translated to SQL and runs on the db site to returned the corresponding list.

    Thursday, January 17, 2019 12:38 PM
  • User-821857111 posted

    A concern stops me -whisper to my ear- "What if dapper guys decide to stop the project in future? What will happen to your project?
    The Dapper guys are the least of your concerns. Microsoft and a very long history of stopping further development on projects.

    Thursday, January 17, 2019 1:12 PM
  • User475983607 posted

    fatihbarut

    Could you explain little bit more about the powerfullness of the LINQ?

    And what does EF with LINQ means? Can EF be without LINQ? 

    LINQ stands for "Language Integrated Query".  The acronym says it all IMHO.  When combined with EF, LINQ solves the tedious problem of writing code that converts a generic result set (dataset) into a collection of strong types or the opposite, strong types into an INSERT.   Delphi is a strongly typed language so I'm guessing that you've always used datasets.

    The problem with DataSets is they are framework specific and do not necessarily travel well between platforms.  If you write your code to use basics types, string, int, date, etc.  Then the types are easily moved between platforms.  This is not a new idea...

    As a web site dev you're constantly serializing data.  So back in the old days you had to write a lot of repetitive boring conversion code.  It's a lot of time consuming work.  Linq to Entities solves this.  It comes with a bit of overhead but we had this overhead anyway as we had to write the conversions ourselves.  I'm happy to let LINQ build my types knowing what I had to do in the past.

    I recommend setting aside so time and learning the basics.  Try to understand the problem the technology solves.

    Thursday, January 17, 2019 1:29 PM
  • User-887854963 posted

    Hi fatihbarut,

    So a few thoughts on your thread and its questions.

    "However, I will be fully honest, I hate entity framework. It is neither SQL nor something else. It is just confusing."

    Sorry to hear you're frustrated with the framework. There's no reason to hate it though, why not ask for help with the confusing parts, it could lead to the framework being improved for everyone. Once you learn it you might even love it. Also you're right, it's not SQL, it's an ORM mapped to LINQ (https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/linq/).

    "Could you tell me who the haven created this framework and why?"

    Looks like an official Microsoft Project according to it's GitHub Repo (https://github.com/aspnet/EntityFrameworkCore). You can see a list of its contributors at https://github.com/aspnet/EntityFrameworkCore/graphs/contributors they all worked together to make it possible. Be considerate though, many of these people donated their free time to make this possible.

    "Believe me, if I weren't afraid of SQL injection and other kinds of hack or something I would use ADO net with SQL."

    Even with an ORM like EntityFramework, you still need to follow best practices and validate / sanitize user input (The ORM may be able to do some or all of this for you, read the docs). Using an ORM doesn't necessarily mean you're immune to SQL Injection, be careful, mistakes can still happen.

    "Any help would be appreciated."

    Happy to help :)

    On last thing, sometimes reading all the docs can be an overwhelming task. While it's not free (unless your organization pays for you), Lynda provides 1000s of courses on C#, ASP.NET (core) stuff, including courses on LINQ and EntityFramework Core.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Saturday, January 19, 2019 9:03 PM
  • User379720387 posted

    No, you can use SQL queries without EF.

    EF was designed to put an abstraction layer between db and code.

    But there are certain benefits of using EF.

    If your app does a lot of different db interactions after a form submits you can create a do or die where all db interactions happen all together, or non of them happen.

    Another benefit is on the coding side, much easier to navigate through the Entity model than it is to remember where all the finer details of the data structure.

    The downside is that it is not faster than SQL queries, and EF is not 100% reliable rebuilding the Entity model after you make changes to tables.

    Sunday, February 3, 2019 9:22 PM
  • User283528319 posted

    No, you can use SQL queries without EF.

    Thanks. But after time I realized EF is really cool <g class="gr_ gr_197 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling multiReplace" id="197" data-gr-id="197">beside</g> I have <g class="gr_ gr_196 gr-alert gr_gramm gr_inline_cards gr_run_anim Grammar only-ins replaceWithoutSep" id="196" data-gr-id="196">plan</g> to migrate my project from <g class="gr_ gr_120 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" id="120" data-gr-id="120">mysql</g> to <g class="gr_ gr_140 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling" id="140" data-gr-id="140">mssql</g> in time which is not possible without injecting dependency with EF

    Monday, February 4, 2019 4:58 AM
  • User1120430333 posted

    wavemaster

    No, you can use SQL queries without EF.

    Thanks. But after time I realized EF is really cool beside I have plan to migrate my project from mysql to mssql in time which is not possible without injecting dependency with EF

    That all depends upon how you architected the data access. It should not  matter what the underlying database technology is if using an abstraction layer above the database technology.

    Monday, February 4, 2019 7:52 AM