VS2008 and higher:: Curiosity

I was wondering for those who are developing in VS2008 or higher are taking advantage of LINQ and language extensions not because they are something different but because they make development easier with consistency in coding and maintenance?

Simple everyday example makes string to integer method based

Code:

---

<System.Diagnostics.DebuggerStepThrough()> _
<Runtime.CompilerServices.Extension()> _
Public Function ToInteger(ByVal value As String) As Integer
    Return Convert.ToInt32(value)
End Function

---

Keeping functional, reusable code behind away from business logic and novice developers and allows for easy maintenance similar to the next example

Code:

---

<System.Diagnostics.DebuggerStepThrough()> _
<Runtime.CompilerServices.Extension()> _
Function CurrentRowCellValue(ByVal GridView As DataGridView, ByVal ColumnName As String) As String
    Return GridView.Rows(GridView.CurrentRow.Index).Cells(ColumnName).Value.ToString
End Function

---

Lastly anyone using LINQ to quickly test queries as shown below?
(Code below is to show a concept, I code with database classes)

Code:

---

Using cn As New OleDb.OleDbConnection( _
    "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=data\demo.mdb;")
    Dim da As New OleDb.OleDbDataAdapter( _
    "SELECT PersonName, ContactPosition FROM People;", cn)
    Dim ds As New DataSet

    da.Fill(ds)

    Dim dv As DataView

    dv = ds.Tables(0).DefaultView

    dv.Sort = "PersonName"

    ' The following perhaps come from a textbox etc.
    ' in a real application
    Dim InsertName As String = "Jane Smith"
    Dim InsertTitle As String = "Manager"

    Dim result As Integer = dv.Find(InsertName)
    If result = -1 Then
        Console.WriteLine("Adding")
        cn.Open()
        Dim cmd As New OleDb.OleDbCommand With _
            {.CommandText = _
              <SQL>
                INSERT INTO People
                        (PersonName, ContactPosition)
                        VALUES (<%= InsertName.SingleQuotes %>,
                                      <%= InsertTitle.SingleQuotes %>)
                </SQL>.Value, _
                .Connection = cn}
            cmd.ExecuteNonQuery()
    End If
End Using

---

Your first extension has a flaw. Won't work if the string isn't a number. Will throw an error. Would be better to use the TryParse method instead, then return a default value if the string fails conversion.

No comment on the second one as I normally get my data from the underlying data rather than the grid itself.

Lastly, I use a lot of LINQ. It's a real time saver. I've converted previous loops that used the .Select method of the datatable, rolled them over into their LINQ equivalents, and shaved off considerable amounts of time. Mostly I use LINQ to Object. Not 100% sold on LINQ to SQL directly. Two things in LINQ that I take the most advantage of: 1) Lambdas... I use a lot of Lambdas to select, transform, and perform calculations on my data. 2) LINQ to XML - being able to transform my datatable into an XML document... along with using Lambdas to control what data is selected... Now I can transform my data into an XML document, and send it all over to my sproc all in one chunk, rather than making repeated calls to the sproc for each row. Yet another performance gainer.

-tg

Thanks for your reply.

In the first extension you are right if you do not know what you are consuming. I am using mine without any issues as I know what I am asking for and why there is no exception or assertion. usually if I am up against unknown types I will not use an extension and will use logic with TryCast but not within an extension as I like extensions to be fairly open and not constrained.

Lastly I was not looking for comments on the extensions shown but instead extensions in general along with LINQ.

Quote:

---

Originally Posted by techgnome

Your first extension has a flaw. Won't work if the string isn't a number. Will throw an error. Would be better to use the TryParse method instead, then return a default value if the string fails conversion.

No comment on the second one as I normally get my data from the underlying data rather than the grid itself.

Lastly, I use a lot of LINQ. It's a real time saver. I've converted previous loops that used the .Select method of the datatable, rolled them over into their LINQ equivalents, and shaved off considerable amounts of time. Mostly I use LINQ to Object. Not 100% sold on LINQ to SQL directly. Two things in LINQ that I take the most advantage of: 1) Lambdas... I use a lot of Lambdas to select, transform, and perform calculations on my data. 2) LINQ to XML - being able to transform my datatable into an XML document... along with using Lambdas to control what data is selected... Now I can transform my data into an XML document, and send it all over to my sproc all in one chunk, rather than making repeated calls to the sproc for each row. Yet another performance gainer.

-tg

---

I'm very much with techgnome. I use a lot of LINQ to Object, and don't see LINQ to SQL as worthwhile at all; primarily because only MSSQL supports it; and it's typically the last database I'm programming for.

I use it to sort and aggregate a lot of data though. The aggregation is where it saves me the most time as I can select and aggregate a collection of objects in one statement. I also use a lot of lambdas too in my code.

Linq to 'stuff' and lambdas, yes. It's a great addition to the language.

Linq to Sql/Entity Framework, yes, but it's not a joy - in the end, they're crap for performance-intensive apps.

Extension methods, only sometimes. It's easy to get carried away with extension methods but other developers will lose visibility of what's going on. I don't find that extension methods make maintenance easier.

Quote:

---

Originally Posted by Jenner

I'm very much with techgnome. I use a lot of LINQ to Object, and don't see LINQ to SQL as worthwhile at all; primarily because only MSSQL supports it; and it's typically the last database I'm programming for.

I use it to sort and aggregate a lot of data though. The aggregation is where it saves me the most time as I can select and aggregate a collection of objects in one statement. I also use a lot of lambdas too in my code.

---

Thanks for your comments. I am with you on LINQ to SQL as my environment is mainly IBM-DB2. Also agree with the use of Lambda but have found it to be a struggle to get other developers (many are short timers) to use Lambda even after they have seen how it can make life easier.

I resisted Lambas at first because I didn't see the point... and I didn't understand them. Fortunately I found myself in a position where I finally understand how they work and make my life easier, I get the point. Now I'm not sure how I ever got along w/o them.

-tg