views:

33

answers:

1

Within my application i have a PUBLIC customer class...

Public Class Customer
    Public Name As String
    Public Surname As String
End Class

Then i decided to use LINQ to SQL within my application. After adding the MyDatabase.dbml class, errors showed up since LINQ creates public properties too

<Column(Storage:="_Name", DbType:="NVarChar(50) NOT NULL", CanBeNull:=false)>  _
    Public Property Name() As String
        Get
            Return Me._Name
        End Get

Here are some errors..

'Name' is already declared as 'Public Name As String' in this class.

'SurName' is already declared as 'Public SurName As String' in this class.

Ok. Thats logical.

But what is the best-practice i should use in the future? I would not like to use the Name and Pluralization options mentioned in ScottGu's blog or rename the properties of my Customer class.

Is there any trick that i am missing?

A: 

Your original code didn't have properties. It had public fields. They a bad idea, basically.

You should just remove the original fields, and use the ones that LINQ to SQL has generated for you. Why would you want two fields (_Name and Name) storing the customer's name, for example?

Jon Skeet
Hello Jon! Actually the original code has properties. What i wrote above is an example. Unfortunately i cannot remove the original ones. (You see it would be easier to write the application from scratch :)
Chocol8
@strakastroukas: Examples are generally more useful if they actually represent the real situation. Now *why* can't you remove the original properties? Do you actually need the existing classes to become LINQ to SQL entities, or could you have separate classes?
Jon Skeet
Basically i would not like to remove them because i am making a lot of checks within the properties. I do not want the existing classes to become LINQ to SQL entities. I just want to learn LINQ and create XML files from my database.
Chocol8
@strakastroukas: If you don't want the existing classes to become LINQ to SQL entities, then create the LINQ to SQL classes with different names, or in a different namespace etc.
Jon Skeet
Aha! I 'll take the different namespace option! Thank you.
Chocol8