![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
best way to study, read up on asp.net
- Thread starter umcpgrad
- Start date
Different from what?
Answers can only be as good as questions asked. You'll need to clarify what exactly it is you want to know.
Assuming you are actually talking about programming and not HTML forms (though an HTML form hooked into some sort of sendmail-ish mailer will let you send HTML form content): If you are starting at zero knowledge then you may as well learn MVC instead of webforms, still using .Net. If you don't care about performance/scaling then you could use the Entity Framework which will make some of what you may want to do somewhat easier.
See: http://msdn.microsoft.com/en-US/data/ee712907
He specifically started off stating "I am trying to create a webform". Although I agree, it is very confusing without a clear question
I am curious about this statement, specifically the scaling part.
He specifically started off stating "I am trying to create a webform". Although I agree, it is very confusing without a clear question
Webforms, I know, see: http://www.asp.net/web-forms
Entity Framework is just an example, but in Ultra-Fast ASP.NET 4.5 the author goes on to explain
Later on in the text he mentions that the fundamental problem is that all of these solutions accomplish ease of use in no small part at the expense of number and complexity of queries, hence scalability is poor. The book is a really good read.
http://ayende.com/blog/156577/on-umbracos-nhibernates-pullout describes a very specific case in which an open source CMS failed a major version (and literally years of manhours invested) because of the over reliance on ORMs and poor understanding thereof. Good comments there too.
If you aren't building the next Amazon then EF is a good choice for sure, but if there's even only a small chance that you will need to scale out into thousands (or hundreds?) of users then ORMs are likely to cause trouble down the road.
Ok, I'll bite ..., so I at least provided links to some opinion pieces about performance issues with ORMs and/or EF specifically at scale.
Just google for: entity framework performance problem
and you'll find literally millions of sites/articles which gripe about performance (sure, some of if could be user error).
Do you know of any large scale projects that use EF?
You provided links to just that...opinions; but without any attempt a justification, those opinions are completely meaningless.
Neither your nor the quotes you provided form the author give any explanation behind 'why' you/the author feel ORMs (Entity Framework, LINQ-to-SQL, I don't care which you want to talk about as long as there's a good explanation) are slow/poor at scaling. I would prefer to deal with more concrete reasoning than just 'so-and-so wrote a book and he said they're bad at it'.
Well, the dude in the book goes over it in more detail, he basically compares the number of queries generated to do a simple thing and (from memory) it takes like 50 queries with EF vs 7 to do it straight up or some such. I don't have the book in front of me right now, the text I copied was from an online reference.
The more general point is that ORMs add overhead, some of them more overhead than others and the end result is lackluster performance at scale. You can certainly see a non-scientific result of those issues by just googling for 'entity framework performance problem'.
It's possible that those issues were partially caused by user error, but ultimately ORMs are just wrappers and literally no one can deny that there's a performance price to be paid for that abstraction.
The more general point is that ORMs add overhead, some of them more overhead than others and the end result is lackluster performance at scale. You can certainly see a non-scientific result of those issues by just googling for 'entity framework performance problem'.
It's possible that those issues were partially caused by user error, but ultimately ORMs are just wrappers and literally no one can deny that there's a performance price to be paid for that abstraction.
There is some level of a price paid in performance, but you have to look at a few of the positive gains of EF:
- Compile-time syntax validation
- Partial class implementations
- Support for other DB vendors that have existing ADO.Net providers (Linq to SQL only supports SQL Server)
- Complex DB mappings to custom objects (Linq to SQL only supports one-to-one mappings)
However, what hasn't truly been established is the threshold where a performance penalty of using EF is significant or noticeable -- assuming, of course, with a solid DB backend that is properly tuned. There are simply so many other opportunities to affect/improve query performance, that I think dwelling on this thought in an unqualified way (especially given the OP's question) is simply out of scope for this thread.
Last edited:
So clearly you didn't get much out of reading it....that or the author was completely ineffective in articulating his stance.
LOL
His message that ORMs add overhead and that this overhead can and does create performance problems was well received.
...Yes, we've established what he thinks, but what he thinks is of absolutely zero relevance to anything anywhere at any point during the entire existence of the universe. The only thing which could ever matter is why he thinks that way, and you were, unfortunately, unable to explain that.
If you believe statements to be factual without good, sound reasoning supporting them, I honestly feel bad for you. Fortunately, neither the thread starter, nor anyone else in this thread, is forced to just accept anything they hear on the internet to be true 'just because'. So if you would like to continue 'enlightening' us on object-relational mapping, feel free to support the 'facts' you've been providing with some form of intelligible reasoning.
Last edited:
Parmenides
Supreme [H]ardness
- Joined
- Apr 25, 2006
- Messages
- 6,578
EF has a little extra bloat. It sucks to look at when you look at the SQL profiler. They like to make use of nested queries. Really annoying to try to read sometimes. Sometimes it just feels good to just make a stored proc and get the data the way you want it. But yeah, EF does the job nicely, especially with cache to help it out. Honestly though, EF is a little overrated. LINQ to SQL works with just as much development time for most of our purposes. And DataReader really ain't that bad either. Some extra lines with a stored proc is all in many cases.
as for Webforms, that's of the devil. MVC all the way baby
as for Webforms, that's of the devil. MVC all the way baby
trpwakawaka
n00b
- Joined
- Oct 3, 2012
- Messages
- 18
Since you are using web forms, you might as well use the server controls they made to make your life easier.
http://msdn.microsoft.com/en-us/library/vstudio/fkzs2t3h(v=vs.100).aspx *
As for any ORM, the benefits, most of the time, trump the performance implications. A lot of what an ORM does out of the box (plumbing code, mapping, caching, change tracking, lazy-loading, etc..) would take a decent chunk of time. With that said, nothing is a silver bullet. If you want rich features out of the box and aren't too concerned with performance**, use a full-fledged ORM. If you want something that simplifies your life and you don't have to re-invent everything, you can use a micro-ORM. Then, finally, you could always hand-craft all of the code and statements. There are trade offs in every case.
**Keep in mind we are working in ms, not minutes or anything.
*By sharing this information, I'm not condoning the use of WebForms. They do what they do well, but they try to make the web into something it isn't.
http://msdn.microsoft.com/en-us/library/vstudio/fkzs2t3h(v=vs.100).aspx *
As for any ORM, the benefits, most of the time, trump the performance implications. A lot of what an ORM does out of the box (plumbing code, mapping, caching, change tracking, lazy-loading, etc..) would take a decent chunk of time. With that said, nothing is a silver bullet. If you want rich features out of the box and aren't too concerned with performance**, use a full-fledged ORM. If you want something that simplifies your life and you don't have to re-invent everything, you can use a micro-ORM. Then, finally, you could always hand-craft all of the code and statements. There are trade offs in every case.
**Keep in mind we are working in ms, not minutes or anything.
*By sharing this information, I'm not condoning the use of WebForms. They do what they do well, but they try to make the web into something it isn't.
Last edited:
EF has a little extra bloat. It sucks to look at when you look at the SQL profiler. They like to make use of nested queries. Really annoying to try to read sometimes. Sometimes it just feels good to just make a stored proc and get the data the way you want it. But yeah, EF does the job nicely, especially with cache to help it out. Honestly though, EF is a little overrated. LINQ to SQL works with just as much development time for most of our purposes. And DataReader really ain't that bad either. Some extra lines with a stored proc is all in many cases.
as for Webforms, that's of the devil. MVC all the way baby
Stored procedures? Ugh I avoid those like the plague!
You can call a stored procedure in EF, yes.
Parmenides
Supreme [H]ardness
- Joined
- Apr 25, 2006
- Messages
- 6,578
Sometimes simpler and cleaner than certain LINQ querires. But usually LINQ works fine for most cases.
I worked as a hired hand at a company that used stored procedures to do everything. Their entire application was just a stored procedure call(exaggeration but you get the point).