Quick Poll
-
How many of you are still using Linq-To-SQL versus Entity Framework?
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
First off, I try to decouple the data processing from the main code, so that the application is not exposed to the actual query engine used. I tend to use EF as it can get me going quickly. But if there are bottlenecks or other issues I can move to another framework, or go straight to ADO.Net. Optimize where and when necessary. I've just published (with help) a fairly big open-source project on Github, which scans AzDo repos and reports on all kinds of tidbits - things like what version of .Net being used, libraries, NuGet and npm packages, etc. Useful to then determine which apps should be updated, for example if you are using a version of .Net no longer getting security patches. Sorry, rambling a bit. My point is I am considering switching some of this from SQL Server to a non-SQL backend. Easy to manage with all the DB code decoupled.
-
Isn't LINQ To SQL ancient history? :~ I'm using the latest versions of EF myself. Code first and migrations for automatic deployment.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I never did get the hang of Migrations, always seemed to foul things up. Much prefer creating a DB project and code it directly there. Then again, I grew up using SQL Server and just got used to coding it directly.
-
I never did get the hang of Migrations, always seemed to foul things up. Much prefer creating a DB project and code it directly there. Then again, I grew up using SQL Server and just got used to coding it directly.
I did SQL Server for years before switching to code-first and Migrations. Don't want to go back though. All my "SQL" is C# now, and by extension strongly-typed, in source control and automatically deployed. It takes some getting used to and there are some gotcha's, but for me, the pros far outweigh the cons. Even when I have an existing database, I code it like it was code-first.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
More often for me than for others probably.
Well, still possible using EF.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Well, still possible using EF.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Don't care.
Imagine you'd learn something new.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
How many of you are still using Linq-To-SQL versus Entity Framework?
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
Kevin Marois wrote:
Linq-To-SQL
Certainly I do not want to use it. I learned this when I started SQL profiling and found that linq, with no warning at all, will not necessarily convert to SQL. Instead it can pull data in the application and then process it there. This can lead to a single linq expression ignoring the filter clauses entirely and pulling the entire table into the application. Not hypothetical by the way, I have encountered exactly that. I have also seen it do something similar with linq that should have produced a single SQL join. Instead it did two database queries and then correlated the two in the application. In another case it ended up doing a while loop, again from a single linq statement, which resulted in 200+ database calls. My expectation then is that unless the statement is very simple that I will have to profile every linq statement (and variation.)
-
How many of you are still using Linq-To-SQL versus Entity Framework?
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
My app uses Linq-to-SQL, but the data base stuff is just fluff for the customer.
Software Zen:
delete this; -
How many of you are still using Linq-To-SQL versus Entity Framework?
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
None of the above. I use Microsoft.Data.Sql/SqlClient and System.Data.Odbc and convert data tables to POCOs via XmlSerializer or JsonConvert, although I've used Dapper in both of my Blazor projects.
There are no solutions, only trade-offs.
- Thomas SowellA day can really slip by when you're deliberately avoiding what you're supposed to do.
- Calvin (Bill Watterson, Calvin & Hobbes) -
How many of you are still using Linq-To-SQL versus Entity Framework?
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
Starting about 7 years ago, I'd start every project using EF, and then after a while (growing from two hours to two weeks), I'd become so frustrated with EF's inability to do something that was available in Linq2Sql in V1.0, that I switch back L2S. On my last project, it's been 2 years, and I haven't reached that point yet. So, basically, it only took 7 (8?) releases of EF to match the capabilities that L2S had out of the gate.
Truth, James
