November 13, 2009 at 10:43 am
bear in a box (11/13/2009)
Sql statements belong in a DB class. Advanced C# developers even create classes to hold the data returned by the DB class. Until I see a VB.Net project using these standards
now, i am a bit confused. in my previous company, i've always trained my developers to move away from placing sql code in the gui, to make a class holding the custom sql data processing.
...to get read-only recordsets, but send only new or updated data (from gui to custom class to sql.net to server). much better if sql-statements are placed at the server as stored procedures or functions, away from the application itself.
isn't this the concept of clearly defining what objects and classes are supposed to do, for optimization or at least, better maintainability?
From my .Net training....
The idea was that a DB class could be compiled to a DLL and located on a separate machine if needed.
The DB Data classes are nothing more than a simple class that unpackes a row of data, stores it internally, and provides accessor methods for getting to the data. Want the data to be read-only, make the accessor methods read only.
Need to update the data, a method in the DB class updates the data from passed in parameters.
Yes, developing a Data Access class for every table in a large schema, can start feeling redundant fairly quickly, just remember that you are doing it to make the code-behind develper's job an order of magnitude easier.
And yes, I know that you can generate Data Access classes from the schema directly. That is if you have a locked down schema during development, something that I haven't had the luxury of working with yet in my 5 years of working with .Net.
On my personal projects, I tend to create Stored Procedures for Inserts and Updates to the database, but never got around to creating Stored Procedures or pulling data out of the database. Those sql statments reside in the DB class where, IMHO, they belong.
Interestingly, when the shema is updated, the DB class is minimally affected (only the Update and Insert methods) but the Data classes are where the schama changes impact the code more directly. The type of schema change I'm thinking of is an addition or removal of a column of data in a table.
- Eric
November 13, 2009 at 11:12 am
An interesting debate. From the overall tone, I think that lots of people use C# for personal reasons, or because they find work with it, not because it's better than VB.NET.
I think I'd recommend that DBAs choose the one that makes sense to them, understanding that there are more samples in C#. so if you need more guidance, you might lean that way.
November 13, 2009 at 11:14 am
Depends.
Which one is going to pay better?
November 13, 2009 at 11:14 am
Steve Jones - Editor (11/13/2009)
An interesting debate. From the overall tone, I think that lots of people use C# for personal reasons, or because they find work with it, not because it's better than VB.NET.I think I'd recommend that DBAs choose the one that makes sense to them, understanding that there are more samples in C#. so if you need more guidance, you might lean that way.
Makes sense, but you also need to keep in mind that C# jobs are more common than VB jobs. At least, they have been in every job market I've been in.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
November 13, 2009 at 11:20 am
Jeff Moden (11/12/2009)
Heh... I have an odd personal preference... I don't like languages that require semi-colons or line continuation characters. It seems that they should all be smarter than that. 😉
Poor Jeff. :crying: You are going to hate SQL then. Semicolons are going to be required in SQL server soon. :w00t:
ATBCharles Kincaid
November 13, 2009 at 11:27 am
Actually, there are a few things (like lambdas) that are harder to do/not feasible in VB6, but I guess the main reason is that people that come from Java or C++ prefer C# and people that come from VB6 prefer VB.NET, and the average C++/Java programmer is a better .Net programmer than the average VB6 programmer. That's not because VB6 programmers are dumber (when I used to be a programmer, I programmed half in VB6, half in Java, so I have no bias here), but because the OO nature of .Net is easier to grasp for someone with C++/Java background.
November 13, 2009 at 11:32 am
acarlson-861483 (11/13/2009)
GOOD FOR YOU! I sincerely expect that your work SHOULD have improved over 5 years. As you develop in C# you will continue to improve with that as well. Patterns and practices may also change and be invented that will make what we all do now look like a hack.I attribute sample code in books as being highly influential to how well a person writes code as a beginner. I also see a trend to teach patterns, practice and principles along with syntax these days. I suspect we will see better "new" programmers because of it.
C# does NOT force you to write "good code". You can ignore things like encapsulation, separation of concerns, programming to an interface, etc just as easily in C# as VB.Net. I have been the guy to fix lots of poorly written "legacy" C#...
Wow...touchy. You must be a VB person. It's amazing how the VB ppl get so sensitive over a personal opinion. It's also amazing how you only pick this paragraph out and glaze over my disclaimers. It's like Coke vs Pepsi...I like Coke because it tastes better and IS better. Uh oh...an opinion!
November 13, 2009 at 11:37 am
Actually, I don't find the Dean's c# code very readiable either. Everything is left justified. I'd prefer to see things indented so that it is easier to see the logical flow of the code.
November 13, 2009 at 11:41 am
Please stop comparing C# and VB.NET as though you were comparing old VB to C++. None of those old arguments apply. Check out the Reg Gate Reflector. I write all kinds of stuff in VB.NET and my shop is converting to C#. I compare code back and forth all day long.
I thought that I was on the trail of something odd in the C# decompile of one of my VB.NET programs. I got onto the Reflector folks and found out that it and oddity in the reflector decompile. It looked as though there was a bug in For/Next so I wrote up so C# For loops and found the very same odd behavior. It's a bug in all the .NET compilers and I'm not going into any more detail here.
All of the folks that I have talked to that use both say just about the same thing. C# is more widely taught and so you have more people who know it. Hands down the VB.NET development environment (VS IDE) blows the socks off of C#.
From the SQL standpoint VB.NET more closely resembles SQL than does C#. Note that the SQL TRY/CATCH is more VB like than C# like.
I have not tried the C++ front end for .NET or Delphi or Chrome.
ATBCharles Kincaid
November 13, 2009 at 11:49 am
I, too, started with C and C++ and then used VB 5 and 6. I prefer C# largely because of my OO background and because it is less verbose. And there is a slight difference in how C# was processed in the IMSL in its early versions, an extra step to convert the procedural language variables to objects when required. VB was never intended to be an OO language, while C# was specifically created as an OO language. I know later versions have brought VB closer to OO behavior; however, some of the procedural verbosity remains. And my last benchmark of VB in .Net 2008 indicates that some conversion still occurs to make VB behave like an OO language.
For me, curly braces and semicolons are much easier to track and follow than finding IF...THEN...END IF, etc. And since I'm not the world's best typist, it takes me longer to type VB code, and with far more typing errors, than C#, C++, or Java.
November 13, 2009 at 11:57 am
I am a senior .NET developer with 14 years programming experience. I've used 11 languages over the years, including C# and VB.NET. The biggest source of bugs (outside of a bad programmer) is a language which is not strongly typed. And those bugs can be very difficult to track down and can seem intermittent.
C# is strongly typed and VB.NET is not strongly typed. I've had experience tracking down bugs in VB.NET (and other languages) and found several to be caused by type shifting. Those are hard errors to track down and waste a lot of time and budget. But any strongly typed language won't even compile with a type shifting issue, so those languages never get type shifting bugs.
Try to convert and medium sized or larger app from VB.NET to C# and you'll end up finding a few type shifting issues. I've done two VB.NET to C# conversions and found several type shifting bugs in the process. Those problems are just hidden in the code, you're not likely to spot them.
Jason
November 13, 2009 at 12:04 pm
I turn Option Strict on in VB.Net, and if I understand you correctly, that eliminates the problem you describe.
Best Regards,
Mark Lauser
November 13, 2009 at 12:06 pm
Hi Jason,
"C# is strongly typed and VB.NET is not strongly typed."
FYI, add the following declaration to the top of your VB.NET classes/modules; it will get you a lot closer to a strongly typed VB.NET:
[font="Courier New"]Option Strict On[/font]
Having done that you'll expose most of the type-shifting that's happened in the code, catch errors much sooner, etc. It's a great first step if you are porting your code to C#...
November 13, 2009 at 12:18 pm
scole-1025617 (11/13/2009)
acarlson-861483 (11/13/2009)
GOOD FOR YOU! I sincerely expect that your work SHOULD have improved over 5 years. As you develop in C# you will continue to improve with that as well. Patterns and practices may also change and be invented that will make what we all do now look like a hack.I attribute sample code in books as being highly influential to how well a person writes code as a beginner. I also see a trend to teach patterns, practice and principles along with syntax these days. I suspect we will see better "new" programmers because of it.
C# does NOT force you to write "good code". You can ignore things like encapsulation, separation of concerns, programming to an interface, etc just as easily in C# as VB.Net. I have been the guy to fix lots of poorly written "legacy" C#...
Wow...touchy. You must be a VB person. It's amazing how the VB ppl get so sensitive over a personal opinion. It's also amazing how you only pick this paragraph out and glaze over my disclaimers. It's like Coke vs Pepsi...I like Coke because it tastes better and IS better. Uh oh...an opinion!
And I like rootbeer! So VB and C# both suxor! Hahahaha!!!1one LOL!!!!!111!! I win, u lus!
All seriousness aside, I'm assuming you didn't read the part where he stated that he's had to fix a lot of C# code that was poorly written.
I used to have a sig that was a quote. Went something like, "There does not now exist, nor will there ever, any programming language that makes it the slightest bit difficult to write bad code." No language makes a coder skilled. Study, practice and experience do that.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
November 13, 2009 at 12:31 pm
1. I should have use marked the code as code.
2. I copied both samples from http://www.asp.net. I assumed MS could code to their own standards and the c# seemed a fair representation to me so why not the vb?
3. If I do come across non-standard code, I, personally would rather it be c#
4. Speaking of fair comparisons, why did you remove all the white space from the c# code sample? (I could have let this go otherwise.)
Lets try this:
If e.Column.Equals(Me.UnitPriceColumn) Then
If Not Convert.IsDBNull(e.ProposedValue) AndAlso CType(e.ProposedValue, Decimal) < 0 Then
Throw New ArgumentException("UnitPrice cannot be less than zero", "UnitPrice")
End If
ElseIf e.Column.Equals(Me.UnitsInStockColumn) _
OrElse e.Column.Equals(Me.UnitsOnOrderColumn) _
OrElse e.Column.Equals(Me.ReorderLevelColumn) Then
If Not Convert.IsDBNull(e.ProposedValue) _
AndAlso CType(e.ProposedValue, Short) < 0 Then
Throw New ArgumentException(String.Format( _
"{0} cannot be less than zero", e.Column.ColumnName), _
e.Column.ColumnName)
End If
End If
End Sub
void ValidateColumn(object sender, DataColumnChangeEventArgs e)
{if(e.Column.Equals(this.UnitPriceColumn))
{if(!Convert.IsDBNull(e.ProposedValue) &&
(decimal)e.ProposedValue < 0)
{throw new ArgumentException(
"UnitPrice cannot be less than zero", "UnitPrice");}}
else if (e.Column.Equals(this.UnitsInStockColumn) ||
e.Column.Equals(this.UnitsOnOrderColumn) ||
e.Column.Equals(this.ReorderLevelColumn))
{if (!Convert.IsDBNull(e.ProposedValue) &&
(short)e.ProposedValue < 0)
{throw new ArgumentException(string.Format(
"{0} cannot be less than zero", e.Column.ColumnName),
e.Column.ColumnName);}}}
I'll give vb a slight edge here and hope that I don't come across code that looks like this ever. Then I'll go back to rooting for my favorite football team, so to speak.
Viewing 15 posts - 106 through 120 (of 176 total)
You must be logged in to reply to this topic. Login to reply