![]() ![]() We have to manually type out each definition of the tables we want to use, and we have to do our best to line them up perfectly.If we took a code first approach there is a couple of problems : If there is a database of a production system, that already has say 50+ tables, and each of those tables has your usual columns, foreign keys, and constraints. Whether it was called database first before, or just datasets in general if you come from a WinForms background, it simply refers to getting your application to talk to a database that already exists. Even if the end goal is to manage the database in a different way post go live, it’s such a rapid prototyping tool that scales pretty well, so you’re going to want to be using it.ĭatabase First is an interesting approach because it use to be a lot more prevalent. In general, you’re probably going to use a Code First approach for almost every new. A code first approach works across different databases such as Postgres, MySQL etc.Almost anyone can scaffold a database if they know C#, even without having too much knowledge of SQL in general (Although.You have an out of the box way to manage database migrations (So no dodgy “run this script before go live” type go live run sheets).Your code is always talking to a database schema that it has control over, therefore there is rarely a “mismatch” in column types, table definitions etc.The benefits of using a Code First approach are numerous : ![]() Additionally, if you have DBA’s who love things like stored procedures or views, while these are doable in Code First, it can become unwieldy very fast. It can be hard to map out a database schema to the 9th degree when everything is written in C#. The main thing to understand about Code First is that because you are scaffolding the database using C# code, it works well for developers, but not for DBAs or Architects. I’m not going to play off these approaches against each other for the most part, but I want to explain what each one actually means, and why people’s perception of Entity Framework can be very different depending on their usage. But people who endured the days of using that annoying WYSIWYG editor in Visual Studio to manage their database to this day will tell you that EntityFramework is a pile of junk and they will never touch it, even though things like Code First has improved leaps and bounds from where it was. There is some historical damage mixed in here because even though I include Model First in this list, the support for this approach was dropped some years back. By approach, I mean whether to use Code First, Database First, or Model First. But what I started finding was that it all depended on the “approach” to using Entity Framework. There are the developers who find EF intuitive and easy to use, and those who say it is absolute hell to manage. When it comes to developers talking about Entity Framework (and I’m including EF Core in this), I find there is very much two camps. ![]()
0 Comments
Leave a Reply. |