Software Engineering: Latest Library is Panacea?
-
I have been using EF professionally for 10+ years now. Our websites and APIs run using EF. I have no issues with EF and our team of 20+ devs are comfortable using it. Microsoft pushes this technology because it works and it works well for its intended purposes. Its a tool, and like all tools, you either learn how to use it or you don't.
Admittedly, many of the ill feelings towards it go back to its initial release all the way back in 08 and release 2010 or so. It wasn't great then & then we just left it alone. After that we began using the Repository pattern & it made things reasonable. A few questions: 1. is there a good readable book that you would recommend that shows how to use EF for many database "structures" (master/detail, linking tables, etc)? 2. Do you find that it can be used well in cases where there is a master/detail type of relationships & you need to update data? Is it straight forward? 3. Have you found places where you can't get there from here type of behavior? 4. What are the most challenging data inserts & updates you've come across while using EF? Thanks for your input.
-
Still reading this fantastic book, which continues to be fantastic: Modern Software Engineering[^]. There is so much great content in this book, but this from Chapter 3 really strikes a chord (as someone who evaluated the use of Entity Framework numerous times over 15 years but could never feel comfortable with it). It's why many of us eschew, "Just use the latest library. It solves all your problems."
Quote:
We talk a lot about change in our industry. We get excited about new technologies and new products, but do these changes really “move the dial” on software development? Many of the changes that exercise us don’t seem to make as much difference as we sometimes seem to think that they will. My favorite example of this was demonstrated in a lovely conference presentation by “Christin Gorman.”1 In it, Christin demonstrates that when using the then popular open source object relational mapping library Hibernate, it was actually more code to write than the equivalent behavior written in SQL, subjectively at least; the SQL was also easier to understand. Christin goes on to amusingly contrast software development with making cakes. Do you make your cake with a cake mix or choose fresh ingredients and make it from scratch?
EF is not SQL. It's a "table to entity" (or entity to table) mapper; and saves me a lot of work in that area. If the only SQL one knows is "SELECT *", and doesn't ever use stored procs, then there will be issues. I just make sure my "model" goes both ways: code first or data base first; and can use either one at any time to drive changes in the model in either direction.
"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
-
What's worse is the Microsoft Entity Framework uses SQL calls that cannot be optimized by the query optimizer.
That's because you're not using stored procs when you should. EF RUNS ON THE CLIENT.
"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
-
Still reading this fantastic book, which continues to be fantastic: Modern Software Engineering[^]. There is so much great content in this book, but this from Chapter 3 really strikes a chord (as someone who evaluated the use of Entity Framework numerous times over 15 years but could never feel comfortable with it). It's why many of us eschew, "Just use the latest library. It solves all your problems."
Quote:
We talk a lot about change in our industry. We get excited about new technologies and new products, but do these changes really “move the dial” on software development? Many of the changes that exercise us don’t seem to make as much difference as we sometimes seem to think that they will. My favorite example of this was demonstrated in a lovely conference presentation by “Christin Gorman.”1 In it, Christin demonstrates that when using the then popular open source object relational mapping library Hibernate, it was actually more code to write than the equivalent behavior written in SQL, subjectively at least; the SQL was also easier to understand. Christin goes on to amusingly contrast software development with making cakes. Do you make your cake with a cake mix or choose fresh ingredients and make it from scratch?
I bake "guaranteed future employment" cakes with inscrutable ingredients :wtf:
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
-
That's because you're not using stored procs when you should. EF RUNS ON THE CLIENT.
"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
Stored Procedures are evil - they tie your work to a particular DBMS vendor, for a start. That's exactly what they are so loved by those vendors!
-
That's because you're not using stored procs when you should. EF RUNS ON THE CLIENT.
"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
Of course the client code runs on the client. The SQL still runs on the server and should be optimized there.
-
Correct. I don't use those tools. And I hand-craft all of my SQL.
Same here... I have kept very much abreast of all the latest software developments but ave found none to be of much benefit. Most seem to just add a lot of complexity while not really providing any real advantage. Probably the best advancement has been the List(T) implementation. Internally it adds efficiency and provides basically the same capabilities as an ArrayList. However, out of habit, I still use ArrayLists since what I use them for is small sets of data where the internal efficiencies make very little difference. All in all, I still use the basic language constructs of C# and VB.NET as I have always used them, and my code works just fine. Never understood all the superfluous language additions over the years. They seem to don nothing but make the languages harder to understand...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
What's worse is the Microsoft Entity Framework uses SQL calls that cannot be optimized by the query optimizer.
You can use both EF and stored procedures together. Its not a either/or situation.
-
Stored Procedures are evil - they tie your work to a particular DBMS vendor, for a start. That's exactly what they are so loved by those vendors!
Only if you write NON-ANSI SQL and don't understand database performance and security ... and who does that?
"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
-
Of course the client code runs on the client. The SQL still runs on the server and should be optimized there.
That's what I said: Stored procs. And why is that? Fewer round trips. Actually, EF can also run on the server as part of REST, but most like to abuse it only from the client side.
"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
-
Only if you write NON-ANSI SQL and don't understand database performance and security ... and who does that?
"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
Yes but... Microsoft have T-SQL and Oracle have their Pl/SQL (for example) and other database systems have their own equivalents, all of which have little in common. Using Stored procs for data queries using strict ANSI-SQL may be one thing, but most stored procs I have seen use the much more proprietary T-SQL or Pl/ SQL (etc) to move complex data-related logic as close to the database metal as possible - and that locks you in. A few stored procedures are not a big deal to migrate to another DBMS, but any decent sized database application could have several hundred stored procedures (they tend to become habitual), and that makes migrating to a different dbms an expensive proposition, which is exactly the position the vendors want to get you in.
-
Stored Procedures are evil - they tie your work to a particular DBMS vendor, for a start. That's exactly what they are so loved by those vendors!
In 20 plus years of development, I've never had a boss say, change to a different database platform. I feel like this is an argument for the sake of arguing instead of adding actual software value. Using stored procs and embracing a vendor's specific optimizations makes a platform faster. If we expand the idea, do you also eschew cloud computing because it creates vendor lock in?
Hogan
-
In 20 plus years of development, I've never had a boss say, change to a different database platform. I feel like this is an argument for the sake of arguing instead of adding actual software value. Using stored procs and embracing a vendor's specific optimizations makes a platform faster. If we expand the idea, do you also eschew cloud computing because it creates vendor lock in?
Hogan
A twenty year career is quite short. Keep going.
-
In 20 plus years of development, I've never had a boss say, change to a different database platform. I feel like this is an argument for the sake of arguing instead of adding actual software value. Using stored procs and embracing a vendor's specific optimizations makes a platform faster. If we expand the idea, do you also eschew cloud computing because it creates vendor lock in?
Hogan
Trust me, it happens more often than you think. Oracle to SQL Server? Significant cost savings. Either of those to Postgres or similar FOSS dbms systems? Again tempting reduction in licence fees. The obstacle? The cost of overcoming that vendor lock in. If you've never come up against this, you're lucky. No, I don't eschew cloud computing for that reason. With modern containerisation that's nothing like the same problem. "It's never happened to me" doesn't mean it never happens. I've never been shot in the head, but it obviously does happen. So far I've been lucky but I still try to avoid inviting it.
-
In 20 plus years of development, I've never had a boss say, change to a different database platform. I feel like this is an argument for the sake of arguing instead of adding actual software value. Using stored procs and embracing a vendor's specific optimizations makes a platform faster. If we expand the idea, do you also eschew cloud computing because it creates vendor lock in?
Hogan
A twenty year career is quite short. Keep going.
-
A twenty year career is quite short. Keep going.
-
Still reading this fantastic book, which continues to be fantastic: Modern Software Engineering[^]. There is so much great content in this book, but this from Chapter 3 really strikes a chord (as someone who evaluated the use of Entity Framework numerous times over 15 years but could never feel comfortable with it). It's why many of us eschew, "Just use the latest library. It solves all your problems."
Quote:
We talk a lot about change in our industry. We get excited about new technologies and new products, but do these changes really “move the dial” on software development? Many of the changes that exercise us don’t seem to make as much difference as we sometimes seem to think that they will. My favorite example of this was demonstrated in a lovely conference presentation by “Christin Gorman.”1 In it, Christin demonstrates that when using the then popular open source object relational mapping library Hibernate, it was actually more code to write than the equivalent behavior written in SQL, subjectively at least; the SQL was also easier to understand. Christin goes on to amusingly contrast software development with making cakes. Do you make your cake with a cake mix or choose fresh ingredients and make it from scratch?
Most libraries are rubbish. Some are a gems. Seldomly, you will find a diamond[^]. In 2014, we moved our 50 man-year legacy VB6 desktop app to a low code framework, in about 2 man-year. Our new app looks modern, up-to-date, has a wide range of new features, is multiplatform (Web, Mobile and Desktop), extremely configurable, even at runtime, looks uniform, has less bugs, displays dashboards with graphics, extendable and designable reports, even at runtime, for every view, etc., etc., etc., you name it, there it is. The app maps around 600 DB tables, some with hundreds of millions of records. All the SQL commands are built dynamically, via an ORM (XPO). Since then, I have written SQLs marginally only, basically to adjust a few old database design to todays paradigms. The new app is faster than its equivalent written in the previous good old hand written SQLs technology in VB6. Todays' source code is entirely C#. I have never been more happy to go to work since.
-
Correct. I don't use those tools. And I hand-craft all of my SQL.
Most libraries are rubbish. Some are a gems. Seldomly, you will find a diamond[^]. In 2014, we moved our 50 man-year legacy VB6 desktop app to a low code framework, in about 2 man-year. Our new app looks modern, up-to-date, has a wide range of new features, is multiplatform (Web, Mobile and Desktop), extremely configurable, even at runtime, looks uniform, has less bugs, displays dashboards with graphics, extendable and designable reports, even at runtime, for every view, etc., etc., etc., you name it, there it is. The app maps around 600 DB tables, some with hundreds of millions of records. All the SQL commands are built dynamically, via an ORM (XPO). Since then, I have written SQLs marginally only, basically to adjust a few old database design to todays paradigms. The new app is faster than its equivalent written in the previous good old hand written SQLs technology in VB6. Todays' source code is entirely C#. I have never been more happy to go to work since.
-
Still reading this fantastic book, which continues to be fantastic: Modern Software Engineering[^]. There is so much great content in this book, but this from Chapter 3 really strikes a chord (as someone who evaluated the use of Entity Framework numerous times over 15 years but could never feel comfortable with it). It's why many of us eschew, "Just use the latest library. It solves all your problems."
Quote:
We talk a lot about change in our industry. We get excited about new technologies and new products, but do these changes really “move the dial” on software development? Many of the changes that exercise us don’t seem to make as much difference as we sometimes seem to think that they will. My favorite example of this was demonstrated in a lovely conference presentation by “Christin Gorman.”1 In it, Christin demonstrates that when using the then popular open source object relational mapping library Hibernate, it was actually more code to write than the equivalent behavior written in SQL, subjectively at least; the SQL was also easier to understand. Christin goes on to amusingly contrast software development with making cakes. Do you make your cake with a cake mix or choose fresh ingredients and make it from scratch?
sql and stored procedures are a bore to maintain... code is better....debugging etc.....i used third party orms and way better, always avoided stored proc ....
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
-
Its a start. I can't make it go any faster and wouldn't if I could as I'm enjoying every day getting there.
Hogan
Excellent; no-one can ask for more. However I await with interest to hear your feelings when you are tasked with a database migration on a tight schedule and find that... it's stored procedures all the way down 😉😂
