|
I think you guys used very old versions of EF, because I'm using EF for almost every project that I start and the queries are actually very clear and concise. In the end you can even execute your own queries with EF, the same way as you do with Dapper, I'm very satisfied with how EF actually works
|
|
|
|
|
Same thoughts exactly.
A lot of DBA's dismiss the earlier versions and never re-evaluate it again, which is a professional mistake in my opinion. It has improved tremendously in the past decade or so, so much so that I would not start a new project/company without it again.
The main reason for it's success, is that it successfully avoids the constant maintenance and performance issues you hit after 5 years or so doing the typical SQL designs. EF is more complex to maintain initially, but it scales up all the way to enterprise, for a fraction of the cost and with a lot less headaches along the way.
Also, the typical "the queries are bad" response I get is disingenuous. All DB designs allow for bad queries, but with EF you get a sustainable way of solving them, instead of piling up complexity in either your DB design or constantly retraining developers in more advanced SQL approaches. Neither of those are cost effective in the long run.
|
|
|
|
|
I've been a developer DBA, for lack of an actual one DBA, and I can say that if you don't know how a database works, you won't perform well with EF either.
It's a real issue I think, developers forgetting they're talking to an actual database and not some in-memory code and data.
I check the generated SQL for all but the simplest queries (and I've become pretty good at predicting the generated SQL).
There are times when I think, this query is not going to scale very well, and I have to change my LINQ query to generate cleaner SQL.
Also, I do code first, but always check my migrations and how it's actually generated in the database.
I'm checking for names, types, foreign keys, etc.
It's very nice for DevOps and CI/CD though!
All in all, it's made my life a lot easier, but it doesn't take away that I need to know SQL or how a database works.
I've been able to ban views, functions and stored procedures from my life and fix it all in code with good and clean generated SQL queries 
|
|
|
|
|
I've never really like the migrations. I use a project/raw sql to generate and maintain my databases.
Phil
|
|
|
|
|
|
I've been using Entity Framework for about 10 years. Before that, I had 20 years experience in hand-coded SQL queries through stored procedures and views. So, I've used both approaches extensively. This is what I've found.
Against:
1) It occasionally produces poor-performing queries, especially when they are big
2) It consistently produces queries that are very hard to understand
For:
1) It saves a lot of time in the maintenance of stored procedures and views (or the ugliness of in-line SQL, if that's your thing)
2) You get compile-time checking. If I refactor my schema, my code breaks until I fix the problems.
Does it matter in my job?
Yes.
Does it positively or negatively affect database design or performance?
No affect on DB design - I design my database independently then hook EF up to that. It does have an affect on performance though in some cases. Generally, it's fine for simple CRUD operations, but where you have complex joins and grouping it can (but not necessarily will) produce slow queries. I'm generally pleasantly surprised by the perfomance. It produces crazy-looking queries with lots of sub-queries, but they seem to perform OK. I guess the EF designers know what SQL can handle.
My approach is to use EF where EF is fine, then drop into views/stored procs where necessary. The difficulty here is with inexperienced team members who may never get the opportunity to learn to hand-code SQL, so will just rely on EF when they shouldn't. Also, some developers just don't like the idea of mixing strategries and would prefer all or nothing.
Does its use ever cause you any headaches or make your job any easier?
Yes and yes!
The LINQ syntax can get very complex. Sometimes it's just quicker to write the SQL yourself. Occasionally queries need to be written in SQL for performance reasons. It all depends what you are doing really. If you are doing complex transactions on high volumes of data, then EF may not be the best choice for that.
The time saver isn't so much not having to write T-SQL, but on the admin overhead of having to write views/sprocs seperately from the rest of my code. The compile-time checking is the real benefit for me though. In the past, a common problem I had was production bugs due to an obscure view or sproc that wasn't updated after a schema change. Now, I have a limited number of views and sprocs to check, and the rest is caught by the compiler. This is the single biggest advantage for me. It's reduced production bugs and gives me a sense of safety to re-factor.
Cheers,
Carl
|
|
|
|
|
Make sure you understand navigation properties in EF before you go into production 🤯
|
|
|
|
|
EF is an ORM at its core and must be approached as such.
Yes, we use it all the time and it matters greatly to my/our team's job.
If you design your database properly, then EF will work properly.
Most, not all, the EF haters have no clue how to use EF. So, they spout off nonsense about EF, but in reality, they know nothing about it or how to use it properly.
Good luck.
modified 28-Apr-21 6:27am.
|
|
|
|
|
One have to realize it's a tool. And all tools have to be used appropriately.
Just because it doesn't work for everybody doesn't mean it won't work for you. Or vice versa.
Performance: Yeah it's crap compared with ADO.Net, but you know what, in 95% of the cases you won't notice.
Pitfall nr 1: It doesn't remove you from having to understand how a database works.
It doesn't matter if you use Code First or Database First if you're anyway crap at modeling.
For the database I'm working on we have a data entry tool that uses EF. It has probably saved us a ton of time developing it.
For reporting we DON'T use EF. For performance reasons. Yes you can run queries directly in EF, but why add another layer if you're not going to benefit from that extra layer.
So my personal takeaway is that EF is fine for CRUD (and quite a bit more actually), but as soon as your queries are getting more advanced and aggregates a lot of data you need to watch out.
MSBassSinger wrote: Does its use ever cause you any headaches
Yeah, simple tasks as changing the datatype on a column isn't as easy as it should be if you're database first.
|
|
|
|
|
Just a point about what often seen as EF making very large queries for simple things.
If doing something like Get Record Where ID = 5
Quick SQL could be "select * from table where id = 5"
EF will use the full expanded out version, so that * becomes all the fields in the table.
So just like writing suitable SQL quieres, EF needs to be used appropriately. If just want to get 2 fields from a 20 field table, then in EF use .Select and Where in combination, and will generate out suitable query.
|
|
|
|
|
Most DBA's have no practical "application development" experience ... and their designs (and attitude) reflect that.
Asking a DBA about EF, or any ORM, would be like asking them what programming language to use.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
DBAs that are not application developers do have experience in dealing with poorly written SQL by application developers that they have to then clean up and optimize.
An application developer who uses SQLProfiler, is adept at SQL, understands indices, avoids table scans, etc. is a delight to the DBAs that have to manage the databases.
Asking them about EF and other ORMs is in the context of how does the application developer's use of them impact their work. And it does, if you read some of the other posts.
|
|
|
|
|
personally, I've used entity for a couple years, but stopped. I didn't like it, and have gone back to using stored procedures and then the system.Data namespace to use the calls, for multiple reasons:
*i don't need CRUD on all tables
*SPROCs are easy to test and verify results.
*complex joins and other like functions are easier to do in T-SQL before it gets to the app
*Entity framework feels heavy.
but these reasons are mine, and our environment works well with SPROCs.
|
|
|
|
|
I will rail against the use of ANY ORM when given the opportunity.
I've been looking, for the last 10 years or so, for a way to completely rid MVC apps of the scourge that is EF, and have never found anything more descriptive than, "yeah it's possible". I want code, not possibilities.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
In addition to what others said, there are two different EF frameworks:
* EF6 is fine for most business work. It enables fast coding for the 99% of your application, and it's easy enough to use raw ADO.net for the 1% that's performance-sensitive;
* EF Core does not support Distributed Transactions. For most business applications this is a dealbreaker: it's very common to have to write on different databases, even if both are residing on the same server. EF6 will happily join them in a single transaction, EF Core won't. This is why we are still on the .net framework and skipping .net core...
Luca
The Price of Freedom is Eternal Vigilance. -- Wing Commander IV
En Það Besta Sem Guð Hefur Skapað, Er Nýr Dagur.
(But the best thing God has created, is a New Day.)
-- Sigur Ròs - Viðrar vel til loftárása
|
|
|
|
|
I use EF not only with MS SQL, it fits fine also for nosql databases (eg Arango) .
Yes it saves also work for dumb jobs like "list and some actions".
|
|
|
|
|
I thought I was going to get in front of my graphics device drivers by starting with the SSD1306 - a small monochrome OLED display that comes in 3 different sizes/resolutions and runs over SPI, I2C, or (not usually) parallel - the latter of which is basically never available for MCUs - it's either SPI or I2C
It's a simple device. I thought implementing it would be the easiest place to start.
Now keep in mind, I've written this graphics library such that it should seamlessly interface with my device drivers with very little massaging on my part. I've architected it such that I can just lego what is there together with my device drivers.
Or so I thought.
This device has an integrated frame buffer, but you can't *read* the frame buffer over either of those serial interfaces - only the parallel one you never have access to. This isn't a show stopper normally, except it's a monochrome framebuffer, meaning 1-bit per pixel, meaning you have to read 8 pixels in order to write one pixel because you can only write a byte at a time.
So basically, you can't really do random access to the frame buffer at all with this device because of the above.
I had counted on not being able to read the buffer, but I hadn't counted on not being able to do random access when writing the frame buffer. That was a corner I just didn't think around.
Software architecture was being discussed earlier, and I spent some time as a software architect professionally.
What it taught me was no matter how good at it you are, the results are mixed, not consistent no matter how process oriented you are about it. The reason is because of things like the above. We can't predict the future. We can't think around every corner.
Architecture comes with a certain amount of accepting the idea of moving 3 steps forward and two steps back when it comes to design.
There are ways to mitigate this. You can be flexible and code compartmentalized such that if you rewrite part of it you don't have to rewrite all of it.
I saved myself because I use "template polymorphism" instead of standard polymorphism and inheritance in my library, so I don't have a bunch of base class changes to make that will wreck my entire source tree, but it comes with downsides as well.
But you will be rewriting code for any non-trivial project. You will be redesigning bits as you go. Your best efforts are not put in heading all of that off but rather putting it into making your code flexible enough that it will survive having portions of it ripped out and completely rewritten.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: What it taught me was no matter how good at it you are, the results are mixed, not consistent no matter how process oriented you are about it. The reason is because of things like the above. We can't predict the future. We can't think around every corner.
Amen !
I see a paradoxical inverse relationship between the extent to which i may have become secure and confident in my technical abilities ... and ... the extent to which I could enter a state of FUD facing a new project/challenge ... and ... the unleashing of creativity, and out-of-the-box thinking. Of course, I don't mean self-confidence in the broader sense: I speak of FUD that hones the blade of reason 
At the same time, creative "exaltation," as you have novel insights, carries the risk so perfectly embodied in the Narcissus story.
I was lucky that my professional work usually gave me complete freedom to do "architect" whatever, because no one else understood my specialties (the PostScript language, color science, printing).
These daze, I would never claim to have been an "architect" in the profound way I believe Marc Clifton is !
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
I didn't so much claim the role as it was thrust upon me. In fact, I didn't want to go that direction, but I had been a senior developer for so long, headhunters were wondering about me. I had to move at least laterally if not upward, whether I wanted to or not in order to stay commercially viable.
Real programmers use butterflies
|
|
|
|
|
I'm certain you deserve the title 
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
I didn't like doing it, so I'm sure there are others more suited. I am good at systems. I love systems. But politics, not so much, and I found that being an architect involves more interfacing with people I didn't care to interface with than I really liked.
I'm a coder. Give me code. I like design, but I like to do it on my own, or among a small team I lead, where I don't have to deal with politics. Otherwise, I'd prefer to be strictly a coder.
Real programmers use butterflies
|
|
|
|
|
Thank your hubby. You impossible to please.
honey the codewitch wrote: I saved myself because I use "template polymorphism" instead of standard polymorphism and inheritance in my library
Case closed.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Well, it has its drawbacks, like it's possible to put source code that won't compile into production if you do things this way. Code coverage testing becomes much more ... fun.
It can also lead to code bloat, which is one of the main reasons that will cause me to fall back on binary polymorphism.
There is no single silver bullet. I wish there was.
Real programmers use butterflies
|
|
|
|
|
Wow.
I was not talking code.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I didn't see the hubby part. 
Real programmers use butterflies
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
