New Features - C# 4.0
The 1st of Jan 2010 I installed Visual C# 2010 Express, quite appropriate date
don't you think? (Delayed thanks to my lack of bandwidth among other
things, but don't let me get started on that one, sigh)
I know at this point I am a few million years behind writing on this subject, but hey,
better late than never.
Nevertheless, I've been having some fun playing around and reading up on all the
wonderous new features for a while now - new to C# at least.
The focus of this release (version 4.0), is "Dynamic Programming", which is somewhat code word
for "We're compromising to fit/interact with other Tom, Dick & Harry languages". (You guys know
who you are)
The new features can be broken up in four groups:
- Dynamic lookup
Allows developers to bypass static type checking (eg dynamic typing), resolution of dynamic types happen during runtime - finally giving C# variables an identity crises ;) :P (Who am I?)
dynamic a = "Dude"; // I am string a = 10; // No, wait I am an int a = DateTime.Now; // Oh, now I am a date
I suspect this is going to become quite the misused feature over the next few years.
Its great for late-binding and will minimize the amount of code needed in certain cases (eg Type casting) - but potentially quite frivolous.
- Named and optional parameters
Allows developers to specify optional parameters, by giving them default values ( similar to VB, PHP, SQL etc)
// Notice the optional parameters static void test(Int32 i, String s1 = "Test1", String s2 = "Test2") { Console.WriteLine(i); Console.WriteLine(s1); Console.WriteLine(s2); } static void Main(string[] args) { // Excluding optional parameters test(1); // Notice s2, a named parameter test(1, s2: "Test4"); }
- COM specific interop features
Dynamic types, named and optional parameters will greatly improve interaction with COM, what is more bloated Primary Interop Assemblies (eg Office Integration), wont be needed anymore, instead only needed functionality will be included into the referencing assembly.
Remember the following? If you've worked with office automation for example, it will look all too familiar...object missing = Missing.Value; object newfilename = "a.docx"; document.SaveAs(ref newfilename, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing);
If you've ever attempted this in VBA, you'd remember it being a lot cleaner, this is what we see using C# 4.0:document.SaveAs("a.docx");
- Variance
C# 4.0 will support safe covariance (allow more derived return type) /contravariance (allow less derived parameter types) via interfaces & delegates.
Have a look at the following quick example (using delegates), notice the out/in keywords and how they're being used.using System; using System.Collections.Generic; using System.Linq; using System.Text; class a { } class b : a { } delegate T covariance<out T>(); delegate void contravariance<in T>(T value); class Program { static void Main(string[] args) { covariance<b> _b = () => new b(); covariance<a> _a = _b; contravariance<a> _a1 = (param) => { Console.WriteLine(param); }; contravariance<b> _b1 = _a1; } }
Date - 2010-01-12 21:52:13
Comments - 0
New Features - SQL 2008: Table-Valued Parameters (TVP)
SQL 2008 introduced a nifty feature called Table-Valued Parameters (TVP) into its codebase.
TVPs allow developers to pass sets of data to a stored procedure (i.e. passing a table to a stored
procedure parameter).
The first thing we need to do, is define a table type, like this:
CREATE TYPE [dbo].[MyFriends] AS TABLE( [firstname] [varchar](50) NOT NULL, [lastname] [varchar](50) NOT NULL )
Create a little table for our testing purposes:
CREATE TABLE [dbo].[friends]( [friendID] [int] IDENTITY(1,1) NOT NULL, [firstname] [varchar](50) NOT NULL, [lastname] [varchar](50) NOT NULL, CONSTRAINT [PK_friends] PRIMARY KEY CLUSTERED ( [friendID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY]
Next we create a stored procedure using our newly created table type. Note a TVP must be passed as READONLY - which means you can't modify(insert/update/delete rows) it within the body of the routine you're passing it to.
CREATE PROCEDURE [dbo].[addFriends] @friends MyFriends READONLY AS BEGIN INSERT INTO friends(firstname, lastname) SELECT firstname, lastname FROM @friends END
In our C# snippet we create a DataTable, add some rows to it, and pass it to our stored procedure:
using (SqlConnection connection = new SqlConnection(@"Some connectionString")) { using (SqlCommand command = new SqlCommand("addFriends", connection) { CommandType = CommandType.StoredProcedure }) { DataTable dt = new DataTable(); // Add columns dt.Columns.Add("firstname", typeof(String)).MaxLength = 50; dt.Columns.Add("lastname", typeof(String)).MaxLength = 50; ; // Add some rows dt.Rows.Add(new Object[] { "Eugene", "Stander" }); dt.Rows.Add(new Object[] { "Roland", "Cooper" }); dt.Rows.Add(new Object[] { "Jacques", "Brits" }); connection.Open(); command.Parameters.Add("@friends", SqlDbType.Structured).Value = dt; command.ExecuteNonQuery(); } }
How does all of this affect performance though?
A few clues can be found at http://technet.microsoft.com/en-us/library/bb510489.aspx
Summarized in the case of bulk inserts vs TVPs; a formatted data file on the server will perform better using a bulk insert, unless it is a complex operation with less than 1000 rows.
Using a remote client process TVPs will usually perform better, unless its a direct insert with more than 1000 rows.
Date - 2010-01-06 22:58:25
Comments - 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27