Menu
I've been using the SqlCommand class and writing my own T-SQL queries for a very long time. I've stuck with it because I'm comfortable with it, and it probably stemmed from me starting as a windows developer in the days before we had many other great options. I've been doing web development now for about 10 years, and still using it and writing my own query strings. I've written a dynamic class for all my database needs on the fly, all I have to do is write the T-SQL, which I can do quickly and use in any project.
Other developers have got big eyed when they see my code, and encourage me to learn LINQ which I do not like at all.
I'm starting a new project now in ASP.NET MVC and now feel like I should get out of the dinosaur days and move to Entity Framework to handle my data.
I know that the SqlCommand class is the nuts and bolts of the Entity Framework behind the scenes, so I feel like why should I go through the middle man (entity) to achieve the same results and spend time learning something new.
Can someone please explain to me why I need to move on, or if I should stick with what I know?
251
If you'd like to access data from an existing database and tables with Entity Framework (EF) Core in your ASP.NET Core Web API project, you can try to use Scaffold-DbContext command or dotnet ef dbcontext scaffold command to generate code for a DbContext and entity types for your database.
The migrations feature in EF Core provides a way to incrementally update the database schema to keep it in sync with the application's data model while preserving existing data in the database.
The Entity Framework enables developers to work with data in the form of domain-specific objects and properties, such as customers and customer addresses, without having to concern themselves with the underlying database tables and columns where this data is stored.
Conclusion. EF should be considered a great ORM framework which allows faster development, easier and quicker operations to the DB, as long as you are careful and know how it works in order to avoid certain mistakes and create performance problems.
Well, with SqlCommand... If you're doing it right, you've either already written the equivalent of an ORM, or you are spending a lot of time writing code that does stuff like packaging up arguments, and mapping columns to objects. If you're not doing either of those, then chances are you have unsafe code and are passing around untyped DataSets and then doing lots of casting, or you're doing dangerous concatenated SQL queries that are prone to SQL Injection.
The advantage of of using EF (or any ORM) is that it handles the SQL generation, the object mapping, the parameter packaging, and gives you a very powerful query interface that lets you write multiple queries very quickly.
Why write 10 lines of code when you can write one?
Whether or not you use EF is really a personal choice... but if you're doing serious, object oriented development, you should be using an ORM of some kind (maybe even a micro ORM, like dapper or massive). Or write your own micro-orm for that matter.
It's just a huge pain to use ADO without some kind of automatic mapping technology.
139
The main reasons to switch to EF is
I switched years ago (via Linq2SQL) and have never looked back.
Go for EF code first and use migrations.
45
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
