|
For what it's worth, the C# style guidelines on MSDN say to use the lower case.
|
|
|
|
|
It's good for starting religious style arguments over code style.
|
|
|
|
|
True. I didn't intend to but it seems I have. I just wanted to have a gentle Friday afternoon chat about code style... I should have known better!
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
There are lots of tools available to build what I call a pop-up website on the myriads of $5 web hosts. Usually featuring Wordpress.
But they all appear to be aimed at making a Blog.
Is there anything like that I can point someone at for making something more general purpose? Like a customer feedback page, for example? I think this person could build the whole thing, with an SQL server backend even, with a host available. But isn't in a position to set-up a server and hosting and all that entails themselves. He has a "real" business to run.
|
|
|
|
|
John Krause wrote: But they all appear to be aimed at making a Blog. Google for "webshop template".
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Which are templates, for Wordpress?
|
|
|
|
|
Not just Wordpress.
Why does customer feedback go into a database? Wouldn't a form that mails you the result be enough?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
So others can see it too
Kind of like Amazon
I loved/hated this and here's why...
Naturally expectation is lots of love
|
|
|
|
|
|
Be USA, and his problem not mine
|
|
|
|
|
Which reminds me; not my problem
It is weekend.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I haven't used it personally, but I have recommended Wix[^] to someone non-techy. This person found it easy enough to make something with it.
Jeremy Falcon
|
|
|
|
|
I was just coming to make the same recommendation (with the same evidence). Are you me?
TTFN - Kent
|
|
|
|
|
Yes, I am you. But you (I) knew that already since you're (I'm) the one typing this.
Jeremy Falcon
|
|
|
|
|
So, I'm trying to squeeze a bit more performance out of a LINQ query executed by EF. It's used pretty frequently and returns just a page of data at a time, complete with filtering and sorting support for various columns. This thing grabs data from 11 tables, basically a status summary row from a bunch of different operations on a single record.
I go look in the SQL Profiler at the query EF generates and find it's hitting the database about 25-ish times, once for the main page of data (pagable grid) and once for each record in the page to fill in a couple of pieces of data for those records that were accidentally not Included in the original query. OK, not problem, easy fix to remove those extra trips to the database. Quick'n'easy.
I also notice the main page query is a bit ... large. 544 lines of SQL with 19 LEFT OUTER JOINS! Wow. I knew EF generated some crappy SQL but this is ridiculous. The other 24-ish hits are small EF house keeping queries and filling in missing pieces of data from the original page query. Not big deal.
So, I put in a couple of missing Includes in the query code and test it out. Great! Down to five trips to the database instead of 25 and the grid page response is about four times faster than it was. Awsome!
Out of curiosity, I go look at the new SQL for the grid page query. It's now 977 lines of SQL with 35 LEFT OUTER JOINS!! WOW!
Oh, it runs in less than 100 milliseconds.
|
|
|
|
|
To this day, I refuse to trust, or use, EF (or any other ORM) except for the most lightweight interactions.
The exception to that is my own ORM, because it's not a PoC.
Sadly, such attitude is rapidly making me obsolete in this industry, as I've actually never had to touch EF. Not that it isn't easy to learn at least the basics.
Marc
|
|
|
|
|
Marc Clifton wrote: To this day, I refuse to trust, or use, EF (or any other ORM) The key is knowing exactly what's going on.
I love EF, but I'm also aware that it's a layer around your database.
You won't believe how many people forget that!
I've heard people say stuff like "we won't use a procedure because we have EF and we don't want to deal with the database directly!"
Well, guess what, you always deal with the database directly, because even if you're using an ORM it will directly influence the performance of your system!
I just prefer to write my queries strong typed in C# than in SQL, but I usually check whether EF makes a somewhat decent query
|
|
|
|
|
Sander Rossel wrote: I've heard people say stuff like "we won't use a procedure because we have EF and we don't want to deal with the database directly!"
Or do they really mean "don't know how to" rather than "don't want to."
Sin tack ear lol
Pressing the any key may be continuate
|
|
|
|
|
Probably
|
|
|
|
|
Sander Rossel wrote: I love EF, but I'm also aware that it's a layer around your database. Where the database is your actual data-abstraction layer; the one that keeps you from having to track each item in a file you actually loop through, keeping it consistent and correct, and providing an abstract way of quering the data without the developer having to know any offsets or physical structure of the files.
Sander Rossel wrote: I've heard people say stuff like "we won't use a procedure because we have EF and we don't want to deal with the database directly!" Which is a good enough excuse to pass around. The upside is that you no longer depend on a specific database-vendor, you just depend on EF.
Sander Rossel wrote: Well, guess what, you always deal with the database directly No, I use the data-providers provided by the .NET framework. Which rely on a set of database-drivers, mostly MDAC. Those talk to the database directly
Sander Rossel wrote: The key is knowing exactly what's going on. The key! The whole key, and nothing but the key! So help me Codd!*
*) it's required
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: No, I use the data-providers provided by the .NET framework. Which rely on a set of database-drivers, mostly MDAC. Those talk to the database directly Data-providers are for sissies and I don't need database drivers either! When I talk, the database just listens
|
|
|
|
|
I use EF all the time. I have used it for years. For the most part it works. I don't use it for ETL or big data loads etc. I will use stored procs instead.
|
|
|
|
|
Why not write your own sp and use that? Or am I missing the point?
|
|
|
|
|
I could do that, but this thing has been changing as the business keeps changing. It's easier to maintain this one in a migration and maintain strong typing than it is to keep changing the SQL. Also, the other people I work with are not so strong in SQL so it's easier for everyone involved to keep it in EF.
|
|
|
|
|