July 2009 - Posts

About SubSonic

Let me start off by saying that SubSonic is great, it's my DAL of choice for most projects.

It's small it's fast to set up and it has a whole lot of functionality and elegance out of the box.

You can tell I was pretty exited about it by reading my previous entry about SubSonic.

That said there are a couple of things that in my humble opinion can still be improved upon in the project.

Stored Procedures VS Other Data Access in SubSonic

Data can be inserted / Updated in the following fashion in SubSonic.

Insert a new order for instance could be done like this:

Dim order As New Generated.Orders
order.Name = "My Name"
order.ProductID = 1
order.Isactive = True
order.Save()

dim newOrderID as integer = order.Id

Now if there are columns which are not set through the object all will still work out and the object will still be created.

Stored Procedures are called like this:

sps.CreateOrder("My Name", 1, Nothing, True).Execute()

It would offcourse be great if the Stored Procedures would have the same approach as the SubSonic Object but with some extra's:

Dim order As New sps.CreateOrder
order.Name = "My Name"
order.Ordernr = 1
order.Isactive = True
order.Execute()

With some other parts ready to be used:

dim ReturnValue as integer = order.ReturnValue
dim Output1 as integer = order.NamedOutputParameter
dim Output2 as string = order.NamedOutputParameter2

This way the existing functionality surrounding Stored Procedures would have:
A sexy way of dealing with optional parameters.
A good way to set up parameters out of order with the Stored Procedures.
Some very nice ways of communicating with the output parameters / return value.

Alas I seem to be a little late with this blog post since Subsonic 3.0 has already been released.

And released and released and err, updated.

Offcourse I still hope this can be added to a new version of Subsonic.
So that it can get even better.

with no comments
Filed under: ,

Introduction

A while ago there was quite the discussion about what the differences where between VB.NET and C# and what people should use.

After a while it seems that most things where said and it became clear that the C# camp had the most zealous advocates.

Now things have quieted down a lot and it would seem that most people have made their choice and perhaps even changed it in between.

At the time that I wrote my previous post about the subject the statistics where telling us that the usage was about equally divided between VB.NET and C#.

The state today

Today there is a different picture, most of the highly visible people who where actively supporting the VB.NET language have switched to C#.

That probably means that the usage of VB.NET has now dropped a great deal compared to C#.

Looking at job postings etc. it would also seem that C# has won the race.
Which is something which probably isn't that surprising.

A poll by Telerik shows: 69% C# vs 30% VB.NET.
Last year it was: 63% to 34%.

Why did C# win the race

  1. VB.NET got a bad name by being associated with VB6 and it's predecessors, which most wouldn't really consider a respectable language.
  2. C# Has a good name because of the fact that it's modeled by Andreas Helberg the creator of amongst others the Delphi language.
  3. C# has been modeled after more respectable look a like languages: Java / C / C++, which are all languages which are well respected.
  4. Because of the points above there are more job openings for C#.
  5. It seems like a lot less typing to get the same thing done.
  6. More and more projects are done in C# in comparison to VB.NET.
  7. C# pays more money.
  8. People migrating from VB6 sometimes choose C# instead of VB.NET because of a lot of the above reasons.
  9. Almost no people who migrate from Java / C++ are considering VB.NET as a language.

What is happening now

Things are getting worse for VB.NET.
My favorite .NET books (ASP.NET Unleashed) have gone from VB.NET to VB.NET + C# to C# only.

People who use to be prolific VB.NET programmers are also migrating.

What are the current differences in the languages

Taken from wikipedia:

Features of Visual Basic .NET not found in C#
  • Variables can be declared using the WithEvents construct. This construct is available so that a programmer may select an object from the Class Name drop down list and then select a method from the Declarations drop down list to have the Method signature automatically inserted
  • Auto-wireup of events, VB.NET has the Handles syntax for events
  • Support for optional variables (this will also be available in C# beginning in version 4.0). This is typically used to provide easy interoperability with native code
  • Marshalling an object for multiple actions using an unqualified dot reference. This is done using the With ... End With structure
  • IsNumeric evaluates whether a string can be cast into a numeric value (the equivalent for C# requires using int.TryParse)
  • XML Literals
  • Inline date declarations by using #1/1/2000# syntax.

Features of C# not found in Visual Basic .NET
  • Allows blocks of unsafe code (like C++/CLI) via the unsafe keyword
  • Partial Interfaces
  • Iterators and the yield keyword
  • Multi-line comments (note that the Visual Studio IDE supports multi-line commenting for Visual Basic .NET)
  • Static classes (Classes which cannot contain any non-static members, although VB's Modules are essentially sealed static classes with additional semantics)
  • Can use checked and unchecked contexts for fine-grained control of overflow/underflow checking
  • Auto-Implemented Properties (as of C# 3.0[4])
  • Implicitly Typed Arrays

Other characteristics of Visual Basic .NET not applicable to C#
  • Conversion of Boolean value True to Integer may yield -1 or 1 depending on the conversion used
  • Assigning and comparing variables uses the same token, =. Whereas C# has separate tokens, == for comparison and = to assign a value.
  • VB.NET is case-insensitive.
  • Type checking is less strict by default. If the default is left in place, It will auto convert type without notifying programmer, for example:
        Dim i As Integer = 1
        Dim j As String = "1"
        If i = j Then
            MessageBox.Show("Bad comparison")
        End If

It should be noted that changing this default (known as 'Option Strict') is widely considered best practice for VB development.

Other characteristics of C# not applicable to Visual Basic .NET
  • By default, numeric operations are not checked. This results in slightly faster code, at the risk that numeric overflows will not be detected. However, the programmer can place arithmetic operations into a checked context to activate overflow checking.
  • Addition and string concatenation use the same token, +. Whereas Visual Basic .NET has separate tokens, + for addition, and & for concatenation.
  • In Visual Basic .NET property methods may take parameters
  • C# is case-sensitive.
  • C# does not allow optional parameters (this will be available in C# beginning in version 4.0[2]).

Conclusion

The fight is over and C# won, not that VB.NET isn’t a valid option.
As you can see from my list I think that technical superiority isn’t the reason that C# is winning the race.
It still has my vote for a lot of things. But I don’t expect to be programming in VB.NET a lot in coming jobs.

with 5 comment(s)
Filed under: , , ,