|
Anna-Jayne Metcalfe wrote: particularly when said code was written by someone lacking experience
That explains why my point of view is biased. We don't have anyone 'lacking experience' in my group. The original comment struck me as a generalization that I don't usually see. If a member or an entire class is static, there's usually a good reason for it.
Software Zen: delete this;
|
|
|
|
|
Same here; however we do still find we've used it where we probably shouldn't from time to time. Fortunately, we're not shy about aggressive refactoring so it's usually no big deal to change it when required.
Anna ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
Anna-Jayne Metcalfe wrote: we're not shy about aggressive refactoring
Anna? Shy? Pshaw  .
Seriously, though, that's one of the things I'm appreciating more and more using C# and .NET. The metadata available to the IDE enables some seriously cool features that lower the barriers to frequent refactoring.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: Anna? Shy? Pshaw
Believe it or not it still happens occasionally. Put me in an unfamiliar environment where I don't know anyone and I still clam up a bit too much for my liking.
Gary Wheeler wrote: Seriously, though, that's one of the things I'm appreciating more and more using C# and .NET. The metadata available to the IDE enables some seriously cool features that lower the barriers to frequent refactoring.
I can imagine. I still prefer C++ though (particularly with the 0x bits added in - the old girl just got a turbocharge!).
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
Gary Wheeler wrote: If a member or an entire class is static,
All inner classes are static in C# - no complaints about them? (Java inner classes may instance-based or static).
So not point in considering static methods evil.
While the hint purpose primary is to point into discrepancy in the design ("did you mean that? Maybe you had something else in mind?"), the static methods would be slightly better optimised in runtime too.
|
|
|
|
|
Thank-you AJ!
I take the view that static should be avoided, but there are times were expedience allows them.
Panic, Chaos, Destruction.
My work here is done.
or "Drink. Get drunk. Fall over." - P O'H
|
|
|
|
|
Anytime. 
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
Makes you realise the utility of code reviews.
At least then someone gets to ask why its been done that way.
|
|
|
|
|
"More stuff" is trademarked? 
|
|
|
|
|
You messed up the code.
Shouldnt the second IsFirst method be called UpdateSecond ?
|
|
|
|
|
I think the "Create New Method" refactoring tool provided by VS automatically makes a method static if the code you selected to be in the body of the method did not use any non-static member variables.
I have occasionally used this "pattern" if IsFirst contains behavior that is generally useful.
|
|
|
|
|
While working with a client to help them clean up their code I found this little gem. They absolutely never knew string.Format existed 
string sql = "select * from table where id={0} and date={1}";
string cmdText = sql.replace("{0}", id.Tostring())
.replace("{1}", DateTime.Now.ToShortDateString());
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
In-code SQL statement is much bigger horror than lack of using String.Format IMHO
modified 19-Nov-18 21:01pm.
|
|
|
|
|
Why is SQL in code such a particular horror?
|
|
|
|
|
Using SQL in code is generally considered bad practice. It can raise maintenance issues and can be exposed to SQL injection attacks to name just a few reasons.
modified 19-Nov-18 21:01pm.
|
|
|
|
|
Admittedly a SP would be much a nicer solution, but in real life you may have to work with databases where you are nowhere near getting authorized to implement a SP.
Think of implementing a reporting system for at large financial institution as a consultant. What do you think their reply would be if you came saying "I need a dozen new stored procedures in your central DB2-database"? The polite answers would be something along the lines of "I'm sorry but that won't be possible", "Are you quite sure this is needed?" etc, etc. The impolite answer would be to find someone else to do the job.
|
|
|
|
|
I agree, that might be the case, but the fact still remains (as CDP1802 noted), that having SQL statement in code formatted with parameters that might come from e.g. UI text-boxes, represents great vulnerability to SQL injection attacks.
Otherwise I understand that sometimes there is no other way, nevertheless in-code SQL can be used wisely or not.
modified 19-Nov-18 21:01pm.
|
|
|
|
|
tinko101 wrote: in-code SQL can be used wisely or not
Exactly.
tinko101 wrote: SQL injection attacks.
Parameterization handles that regardless of where the SQL statement is stored.
modified on Friday, July 9, 2010 12:02 PM
|
|
|
|
|
Did you look at the code in the OP? You can't do SQL injection if your parameter data is strongly typed Int32 and DateTime values. If it was a string that's a different story, but if you are doing extra code to make sure no one is slipping SQL keywords into your ints then you are wasting a lot of time way overarchitecting.
|
|
|
|
|
I was making general observation about in-code SQL. I believe there are some valid causes for using in-code SQL, but it is generally a bad practice. But that is just my opinion which may have something to do with the fact, that I don't need to put SQL statements in code in my line of work, but I do recognize that sometimes there is no other way.
modified 19-Nov-18 21:01pm.
|
|
|
|
|
T M Gray wrote: overarchitecting
|
|
|
|
|
Søren Turin wrote: a nicer solution
Not for a simple SELECT.
|
|
|
|
|
So you're working in a large financial institution where they won't let you create a stored procedure but give you direct update access to tables !!!!!!!!
Tell me which one so I can change my accounts
seriously - the most sensible advantage of SPs over inline code is security - you can give the application(s) access ONLY to stored procedures (and only to certain stored procs if you want) and then easily manage the changing of those stored procedures to avoid someone accidentally or deliberately stuffing something up.
In any decently secured DB the application should never have direct access to the tables (certainly not to update the tables) - as this doesn't prevent the simplest mistake
Update AccountBalance Set Balance = 0;
for example - oops, forgot the 'where'
Making all updates tothe DB go via a stored procedure allows you not only to monitor changes to the processes, but also so make modifications without changing the application and redeploying, and allows you to add (for example) logging easily.
Granted your example was for implementing a reporting system - in that case you may have read-only access to tables and I guess it's a matter of taste as much as anything as to whether you code sql inline or not.
that said, you can unit test an SP, you can check it works independently, you can add logging if it is doing something strange, all without having to redeploy the damn application - so it can be very useful indeed to use them all the time.
Oh, and a nicely formatted SP is much easier to read than inline code - especially where that code is build up out of many strings, so the only way to work out what it actually dies is to run in debug and look at the runtime value...
Hmm - I sound like a SP evangelist, don't I?
___________________________________________
.\\axxx
(That's an 'M')
|
|
|
|
|
I'm an anti-SP evangelist. I have been ever since I had some SPs disappear and bring a system down (granted that was SQL Server 6, but I still don't know the cause).
Having said that, I do see that SPs (at least with SQL Server) offer the things you mention -- but I wonder how many companies actually implement the security and logging features that are available. And mightn't that only be appropriate for in-house systems where you can enforce it, and not so much for software for sale, where the buyer may demand "it's my database and I want access".
My primary concern with SPs is the ease of changing them that you mention -- I see that as a Very Bad Thing. I want all code changes to go through change control, testing, and a proper deployment. Certainly you may have a process for that in place, but in my opinion SPs are too easy to change in the field. They are too open to a properly-authorized but malicious (or inexperienced) employee.
Additionally, what happens to changes to SPs when a database is restored from backup? Don't you have to reapply any changes you made since the backup? That sounds like additional maintenance to me.
As a bonus, not being able to implement a change instantaneously allows a cooling-off period -- you may be able to convince the customer that the change they want is a bad idea.
|
|
|
|
|
PIEBALDconsult wrote: some SPs disappear and bring a system down (granted that was SQL Server 6, but I still don't know the cause).
I can understand your point - but what if a DLL had disapeared without explanation? There's nothing magical about SPs thery are just Database objects.
PIEBALDconsult wrote: software for sale, where the buyer may demand "it's my database and I want access".
I've found that it depends onthe size and computer-savviness of the customer. small customers, yes, customers with any sort of IT dept really hate having their users have access, but demand full access to the IT staff.
If all access to your data is through SPs, then you can give execute only access to everyone (and even require a password as a parameter if you're paranoid) but restrict changing of SPs to only those few.
PIEBALDconsult wrote: all code changes to go through change control, testing, and a proper deployment.
sure - in fact most large sites are much more diligent about this in DB than in code. You can put SP scripts in source control, you can set up tests to test them, you can do source compare and versioning etc. etc. You can do all that you can do with any other source code because the source code for an SP is just that - source code.
PIEBALDconsult wrote: They are too open to a properly-authorized but malicious (or inexperienced) employee.
.. who has open slather to the entire database, in your model, tables data and all! Sure a sufficiently irate tachie could change a SP to regularly do womething - equally they could just change the data, write a tigger etc.
PIEBALDconsult wrote: when a database is restored from backup? Don't you have to reapply any changes you made since the backup?
No - you usually back up databases as a whole - SPs, views, tables, data, keys, foregin keysm constraints etc.etc.etc. and restore them the same - so no additional work at all.
PIEBALDconsult wrote: As a bonus, not being able to implement a change instantaneously allows a cooling-off period -- you may be able to convince the customer that the change they want is a bad idea.
it's rare to make a change to a live site without some thought and process - especially if it is a customer who is likely to be paying for it! Think more of the time when you haven't noticed that this particular bit of program is including customers with the 'inactive' flag set.
With SP, you quickly add 'and active = true' test against the current live code base, and deploy to the database.
With SQL in code you find the code (hopefully only in one place and reasonably formatted to amke it easy to change) and add + " and active = true". Them you test - but hang on - you need to apply that change to the last live version not the current dev version - so you probably need to branch first, then test and deploy the executable to all workstations.
as you are a self confessed evangelist, there'll be no convincing you - so try to keep an open mind and look at the pros and cons. I did some years ago and was persuaded to move to the dark side of SPs - and I haven't looked back.
___________________________________________
.\\axxx
(That's an 'M')
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
