SQL Server for Entity Framework

Do I have to install SQL Server to be able to work with a database while I have EntityFramework Core in my project?

No. Entity Framework is a device that adapts between C# LINQ statements, and various flavors of SQL in order to download database data and transform it into a tree of bjects you can work with in C#.

The specific SQL required is handled by a database-specific provider library, and there are many different providers. This enables EF to work with a wide range of different databases. You do need a database but it does not have to be SQL Server. One popular alternative is SQLite, a file-based database that doesn't need a standalone server software to be installed; it's incredibly powerful for what it is with a featureset that rivals enterprise grade databases like SQLServer, MySQL, Oracle and Postgres

Because you seem to want to use EF without necessarily using SQLServer, here is a link to a microsoft EFC tutorial that uses SQLite:

https://docs.microsoft.com/en-us/ef/core/get-started/overview/first-app?tabs=netcore-cli

Feel free to use any database that there is an EF provider for; the tutorial linked has a link off to various providers, and a simple web search would no doubt also bring a large list so I wont replicate it here

Or does EntityFramework Core cover every need I would have for a database related matter?

As mentioned EFC is purely a devices that sees you use LINQ, makes an SQL, fetches the data and gives you an object. It's the adapter between your code and the database As a high level overview, you'd perhaps have tables:

Department
DepartmentId, DeptName

Employee
EmployeeId, Name, HireDate, DepartmentId

You'd have classes representing them:

public class Employee {
  public int Id {get; set;}
  public string Name {get; set;}
  public DateTime {get; set;}

  public int DepartmentId {get; set;}
  public Department Department {get; set;}
}

public class Department {
  public int DepartmentId {get; set;}
  public string DeptName {get; set;}

  public ICollection<Employee> Employees {get; set;}
}

You'd form a LINQ to retrieve them in some way:

context.Employees.Include(e => e.Department).First(e => e.EmployeeId == 1);

EF would make an SQL (like this, not so readable) and run it:

SELECT TOP 1 * 
FROM Employees e INNER JOIN Departments d ON e.DepartmentId = d.DeparmtentId 
WHERE e.EmployeeId == 1

The database would give back some resultset:

1, John, 1970-01-01, 2, 2, Engineering

EF would pull the data part and store it into objects:

Employee e = new Employee();
e.Id = datareader.GetInt("EmployeeId"); //1
e.Name = datareader.GetString("Name"); //John
e.HireDate = datareader.GetDate("HireDate");  //1970-01-01
e.DepartmentId = datareader.GetInt("DepartmentId"); //2

Department d = new Department();
d.Id = datareader.GetInt("DepartmentId"); //2
d.DeptName = datareader.GetString("DeptName"); //Engineering

e.Department = d;
d.Employees.Add(e);

And you'd get back a C# object with all its fields populated including a related department, with all its fields populated, so you can say e.g. emp.Department.Name (or even emp.Department.First().Employee.Department.First().Employee...- it's a 2-way linked graph so you can do lots of"dot dot dot" navigating around it.

So, when you think about it, EF is doing a huge amount of boring work for you; making SQL, reading the DB, making objects.. All off the back of one line of C# that said "i want the employee with ID 1, and their department"

But it doesn't include the database itself because there are very valid reasons why different people would want different DBs

SQL Server for Entity Framework

Related

Recent Posts