|
CodeWraith wrote: Is it because it's wise to wait a while to see if Mickeysoft ditches it again in favor of something else? Or is it because some frameworks tend to hide a problem's complexity while introducing its own new complexity?
I see you've experienced EF as well. 
Latest Article - Contextual Data Explorer
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Doing so right at this moment.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I find the opposite is true, when a little complexity is required one spends too much time fighting the frameworks simplistic / single dimensional approach to get the task done.
Signature ready for installation. Please Reboot now.
|
|
|
|
|
Sacrilege! Mickeysoft never falls short of any expectations!
Again, before the fanbois recover from their shock, let's get their outcry out of the way: You must be a hater who always hates and is easily confused by facts. You are also a troll who enjoys stomping on their tender feelings. 
Also, this has become #3 on my checklist when to avoid putting too much time in Mickeysoft's grand new thingie.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
As long as you realise the language you use means no-one is going to take you seriously, it's all good.
|
|
|
|
|
What gave you the impression that I'm still around here for anything serious?
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I was just checking that you knew no-one is going to take you seriously, I'd hate to see you wasting your time.
|
|
|
|
|
How nice of you. And now try your trolling luck somewhere else. It's your time you are wasting right now.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Marc Clifton wrote: So glad I don't use EF!
Yeah, EF seems to be created for devs who don't want to actually think about the database as being a separate thing. However, at this point, the db is still a separate thing.
And if you attempt to blithely roll on as if the db is not a separate thing then you will either:
1) pay the price for it
2) cause someone else down the road (after you are gone) to pay the price for it
Wouldn't It Be Nice?
It would be nice if our code just serialized to a structured format without ever having to think about it.
It would also be nice if my car powered itself from all the electrons in the atoms that surround it.
Free energy!
|
|
|
|
|
raddevus wrote: EF seems to be created for devs who don't want to actually think about the database as being a separate thing
It's an ORM, so its purpose is to abstract the domain knowledge in the db into object orientated code without the developer needing to concern themselves with the technicalities of the data access methods. "Code first" is only used by proptypers and school students, it isn't used in the "real world" so it's fairly hard to completely forget you're using a separate database, and any decent developer will be well aware and they'll also ensure the code they're writing isn't going anything daft at the database end. Any technology can be used badly, criticising something because it *can* be used badly does nothing but make me question the motives of the person doing the critisiing.
|
|
|
|
|
|
raddevus wrote: I've just seen it get people down a road in the past where they hit a dead end with no way out.
Then they're bad developers, I have no issues with EF.
raddevus wrote: I'd like to see your rebuttal to OP because he is the one who said he is glad he doesn't use it.
He's just an old man who is scared of anything new
|
|
|
|
|
I successfully avoided using EF up until last year for some MVC stuff I'm doing.
I don't like it. I was happy with my home-spun ADO db class, although my home-spun class really does need to be bolstered with transaction handling. Even so, it's never really failed me yet. I'd also much rather handle my upserting and data retrieval via stored procs (I'm a strong advocate for putting db crap in the db).
".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
|
|
|
|
|
John Simmons / outlaw programmer wrote: successfully avoided using EF up until last year for some MVC stuff I'm doing.
I've avoided it because it seems like it's overly engineered. Way too much code and technology for something that just wraps ADO anyhow.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Most of the time, the use of EF (or any ORM for that matter) is driven by management's desire to get something out "fast", and efficiency is NOT a consideration in those decisions. Many times, using EF is like using a hammer to kill a flea.
I'm actually torn with regards to using or not using EF. On the one hand, it doesn't require you to write BOTH ends of the database access. On the other hand, if you change the model, you have to do gyrations to update the database to match the model using the package manager console. In my case, the package manager console refuses to work because of some stupid-ass security policy override regarding powershell script execution, so I'm stuck with having to manually change the database ANYWAY. How stupid is that?!
I think I'm going to seriously explore moving over to my ADO class. My only concern is the OWIN stuff that MVC uses. There's a LOT of code that's deeply reliant on the use of EF. I wish they would change the template to allow us to select the ORM (or no-ORM code) of our choice. These frameworks are supposed to make our lives easier, but they actually don't when it comes to getting closer to the metal.
".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
|
|
|
|
|
John Simmons / outlaw programmer wrote: My only concern is the OWIN stuff that MVC uses. There's a LOT of code that's deeply reliant on the use of EF. I wish they would change the template to allow us to select the ORM (or no-ORM code) of our choice. These frameworks are supposed to make our lives easier, but they actually don't when it comes to getting closer to the metal.
How can that be?
As I understand them, the MVC/MVP patterns strictly separate presentation, logic and data access. They have different takes on where to draw the separating lines, but data access is always abstracted away into the model.
How can then the 'front end' depend on the EF, unless it's actually MVC in name only?
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Look at the controllers. Everything generated as part of a MVC template assumes the use of EF, and the code in the controllers reflects that. You would have to re-engineer all the controller code to use ADO. Not only that, but you'd have to do it for every MVC app that you create unless you come up with your own solution template. I don't know if there are currently any ADO-based templates available on NuGet.
".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
|
|
|
|
|
You're confusing Identity and possibly "scaffolding" with MVC, they are two separate things but the standard MVC template allows you to include Identity as a way of managing users if you choose to and that uses EF under the covers however you're not exposed to it. If you don't want to use Identity then don't, it's modular anyway so if you want to write an ADO provider for it you're more than welcome to do it, I don't doubt someone out there already has and you just need to download it. Same thing with scaffolding, these things are really there for prototypers and students. I've lost count of the number of "professional" web sites I've written and I've never used scaffolding once. If you don't like it, don't use it, no-one is forcing you too. You can use ado with MVC if you want, there is nothing stopping you, you might just have to do more of the coding yourself. MVC is a presentation framework, it doesn't care what you use to access the database or even if you have a database at all, use anything you want.
Your views on MVC aren't uncommon among newbies, as a default "MVC project" can indeed encompass many things (a project can include an ajax framework, jQuery, bootstrap, EF, Owin, Identity, WebApi etc) and it's common for people to think that all of these things are "MVC" and that MVC somehow needs these things but that's not true, that's just MS giving you an all-singing-all-dancing default project *if you want it*. It's up to you to recognise the technology boundaries, how they interact with each other, and what to replace if any don't float your boat. If you want pure MVC and for you to control everything then choose the empty MVC project and that's exactly what you'll get.
|
|
|
|
|
F-ES Sitecore wrote: that's just MS giving you an all-singing-all-dancing default project *if you want it*.
And there is the problem, a newbie automatically uses their template to create their first project and is instantly overwhelmed by the complexity of "MVC". And at that stage they don't know enough to pick the bits they really need.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
lol if they only gave you a blank project you'd complain it's too much of a learning curve, they give you a complete project and you complain because...well...I don't really know why you are complaining. If you want to learn MVC then get a book on it, do some courses, the default projects are not there to teach you MVC but to give you a jumping point.
|
|
|
|
|
EF is just one of many things designed to keep junior developers from becoming senior developers.
And to allow PHBs to never hire senior developers.
|
|
|
|
|
I've had the odd issue but, for the most part, it works reasonably well. I can't recall the last time I used my ADO library.
Keep your friends close. Keep Kill your enemies closer.
The End
|
|
|
|
|
I've found EF to be difficult to work with especially if you want to do anything out of the box.
and it seems like everything I want to do with EF is out of the box.
Everyone has a photographic memory; some just don't have film. Steven Wright
|
|
|
|
|
I use EF for my API - it works great, probably because I don't use code first.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
GuyThiebaut wrote: I use EF for my API
Wait.
Do you have a layer (Facade) between your API and the EF?
I'm just kidding.
No one does that.
Just wanted to scare you.
Am I funny yet? (Most people are saying no.)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
