MySQL connector VS MySQL Entityframework

Saadia

Member
Joined
Dec 2, 2022
Messages
11
Programming Experience
1-3
hello
just want to make me clear between the two options, that which one is better to use
E-commerce web application to be developed with MYSQL DB and .net core MVC 6

1. connector

1671291757342.png


2. EntityFramework
adding NUGET packages

Please suggest which one is better to use and what are the benefits of both methods,
kindly suggest some tutorial to follow
 
Solution
thanks for pouring your thoughts.
what I have understand is both methods are fine to use, should use of of them under the convenience.
right?
Use EF; it's more convenient, safe, and makes for simpler code

If you eventually run into a situation where you need to go more deep or complex than it supports, you can

Install EF Core Power Tools extension. Design your database first. Use the reverse engineer function of EFCPT to turn your database into code. Use the code.

kindly suggest some tutorial to follow

The Microsoft documentation on their product, EF Core, is a good start


That page will eventually push you into "getting started with EF Core"...
If you like handwriting your serialization of your presumably object oriented data in memory to/from the relational data in your database, and you enjoy writing SQL joins, use the former instead of the latter.

If the former becomes too tedious, but you still don't want to have to deal with the bugs/quirks in Entity Framework, use Dapper to help with the drudgery.

I avoid using EF because of the bugs and quirks I've hit, but that is because I try to push it to extremes. For most normal CRUD operations, and relatively simple object graphs, EF will probably give you the most bang for your buck after going up it's learning curve.
 
Also your experience level will matter. If you are just following tutorials and on the learning curve, almost all of them assume you are using EF.
 
Neither is inherently better than the other. Using Connector/NET means using ADO.NET directly. Other data access technologies, including EF, will generally use ADO.NET under the hood.

Personally, I think that most developers would benefit from using ADO.NET directly to begin with, to get a feel for how the pieces work and fit together, then learn how to use an ORM, like EF, layer on when they tackle more complex projects. Most people don't want to take the extra time to learn something they don't plan to use long term though.
 
It's interesting that calculus teachers also believe that students need to learn how derivatives and integration works under the hood -- grade us on learning how it works over about a semester and a half, and then teach us the shortcuts which most engineers use day-to-day over the last half semester. Could they have just taught the shortcuts over the last half semester? Likely yes. But the question that will hang on the backs of their minds will be: do they understand what those shortcuts actually mean and how they were derived?

On the other hand, modern driving schools don't bother to teach young drivers anymore the chemistry and physics that underlies how a car works. But flight schools still teach the basics of why and how an airplane flies and how their engines and radios work.
 
thanks for pouring your thoughts.
what I have understand is both methods are fine to use, should use of of them under the convenience.
right?
 
More important than convenience: your choice and use should depend on understanding. Recall that you are writing code for an eCommerce site. You will be dealing with a lot of other people's money, as well as their livelihood and reputations.
 
The target OS makes no difference. What makes a difference is how well you choose your tools.
 
thanks for pouring your thoughts.
what I have understand is both methods are fine to use, should use of of them under the convenience.
right?
Use EF; it's more convenient, safe, and makes for simpler code

If you eventually run into a situation where you need to go more deep or complex than it supports, you can

Install EF Core Power Tools extension. Design your database first. Use the reverse engineer function of EFCPT to turn your database into code. Use the code.

kindly suggest some tutorial to follow

The Microsoft documentation on their product, EF Core, is a good start


That page will eventually push you into "getting started with EF Core" which uses command line commands to turn your database into code. This is essentially the same as what I'm recommending you use EFCPT to do - for starters do it like Microsoft recommend but eventually when you get bored of typing commands, you can switch
 
Last edited:
Solution
More important than convenience: your choice and use should depend on understanding. Recall that you are writing code for an eCommerce site. You will be dealing with a lot of other people's money, as well as their livelihood and reputations.
It's for that reason that I'd recommend making a start with something that makes it as difficult as possible to write SQL injection prone code 😃
 
ps; I've just been writing in another thread about the differences between EF and older ways - you can take a look at


If you want to see, for example, what the EF version of downloading data from a DB might look like..
..but note that that code in the other thread downloads all the db into the client. You wouldn't ordinarily do that, so your code would look more like this (this example downloads a person based on their id, updates their name, and saves the changes)

C#:
  var p = db.People.Find(chosenId);
  if(p != default){
    p.LastName = newName;
    db.SaveChanges();
  }

Where does the chosenId come from? Well, perhaps you download a list of all people called "Smith" with their Id and then the admin picks which one to update ..

C#:
  var ps = db.People.Where(p => p.LastName == "Smith").ToList();

  //now show the list of people to the user and get them to pick one person

  //then you can get the Id from the person they chose
 
Back
Top Bottom