|
Interesting
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.
|
|
|
|
|
I don't use either these days, but I haven't touched anything .NET related in like 7 years. Seems like forever.
Nothing against them. These days I'm in the Node ecosystem.
Jeremy Falcon
|
|
|
|
|
Neither: I use SQLConnector, SQLCommand, and Reader / Adapter and DataTable as necessary.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
IDbConnection, IDbCommand, IDataReader, IDbDataParameter, DataTable, DataView. I can use any database system which provides an ADO.net provider/connector (and preferably SQL-92).
By the same token, I can implement a class which is not a database but which provides an IDataReader.
No adapters, I stopped using those years ago; too much trouble. If I recall correctly, the biggest issue I had with an adapter was that it implements concurrency protection (I may have that wrong) which can't be configured off and every once in a while an update would fail because of it -- when in fact having two updates for one record in the same batch was perfectly fine for the particular situation. So I stopped using them and never looked back.
|
|
|
|
|
I use Linq-to-SQL for SQLite in a couple of projects and EF on a couple, I guess depends on the project.
Give me coffee to change the things I can and wine for those I can not!
PartsBin an Electronics Part Organizer - An updated version available! JaxCoder.com
Latest Article: Simon Says, A Child's Game
|
|
|
|
|
I don't have more than a vague idea of what you're even talking about.
|
|
|
|
|
Neither.
Using Dapper or SQLCommand, Reader.
|
|
|
|
|
Isn't LINQ To SQL ancient history?
I'm using the latest versions of EF myself.
Code first and migrations for automatic deployment.
|
|
|
|
|
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.
|
|
|
|
|
Never used either, I don't mind writing the code myself.
|
|
|
|
|
|
Kevin Marois wrote: Linq-To-SQL versus Entity Framework
Neither. It's usually sqlclient unless I have to target non-sql server, then it's ado.net.
I use datareaders or adapters to fill datasets/datatables. CRUD statements are all hand-rolled.
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
I do not use either for Database data, Entity Framework has always had bugs and a lot of overhead that is not necessary in the name of convenience. LINQ is actually awesome with arrays and datsets but not for database query functions. For MS SQL Db SqlConnector SqlCommand SqlAdapter are best in my opinion. For all others, ODBCConnector ODBC Command and ODBCDataAdapter. MySQL would use MySqlData.DLL data connectors and for Oracle use ODP.net. You get the picture right!
|
|
|
|
|
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.
|
|
|
|
|
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.)
|
|
|
|
|
My app uses Linq-to-SQL, but the data base stuff is just fluff for the customer.
Software Zen: delete this;
|
|
|
|
|
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 Sowell
A day can really slip by when you're deliberately avoiding what you're supposed to do. - Calvin (Bill Watterson, Calvin & Hobbes)
|
|
|
|
|
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
|
|
|
|
|
Got a call from a friends mother (97, and generally OK on a computer - she can do 1 sheet booklets in Word, which makes her a wizard in my book): she can't print.
OK, go over to see her1. And it's pretty obvious: there are 183 documents in the print queue, but the first one wants a special paper size and the printer needs confirmation that it's loaded. Empty the print queue,2 confirm the paper tray,3 print a document.
I like simple problems!
1 Because I've played the "fix it over the telephone" game with her before and it's quicker to jump in the car
2 Because they are all duplicates on the "Maybe it'll work this time" theory
3 Because she never reads the display on the printer
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
To be fair, these are printer problems that people have been having for 20 years now, give or take? That is why the are simple. Old school problems.
I find that the more complicated crap gets, the more complicated the problems get. Might be nothing to it, just an observation that may or may not be accurate on my part.
Glad the issue at hand was simple enough to fix.
|
|
|
|
|
Slacker007 wrote: I find that the more complicated crap gets, the more complicated the problems get We build commercial ink-jet printers, where a printing system is 40-80 feet long, and typically costs $1.5-2.5M. We ain't your grandma's DeskJet.
You would not believe how complicated things get. We had a problem several years ago where image registration would drift by a pixel or more over time. It seemed to vary with the amount of ink used in the job, but it wasn't very determinate. After lengthy investigation, we discovered that the press roller used to measure position using a tachometer changed diameter from being heated by the paper going over it. We have to dry the ink (more ink, more power on the dryers), and one of these tach rollers was positioned badly. We moved the roller and switched to one made from a different kind of steel to solve the problem.
Software Zen: delete this;
|
|
|
|
|
"Office" printers (not my own) have always been a mystery to me. I usually circle until someone else clears the "error messages" or whatever.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Fathom below support (10)
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Understand
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|