>> The rule is : the .net member name must permit to distinguish one from to other.
That's a fair convention save for two critical points:
1) C# is case sensitive, so "id" and "ID" are different. But I agree that the mappings shouldn't be case sensitive (because we can't guarantee that SQL implementations will respect this).
2) The compiler and the .NET framework do see a difference between a field and a property, and although their names conflict, they exist in two different contexts internally. So we can't easily treat them the same.
I've noticed it's very common to use case to distinguish between properties and felds in C#.
id => ID
firstName => FirstName
lastName => LastName
etc...I always do this, my co-workers do this and the code that was written by Microsoft that I'm currently working with does this...
So we'll have to find a way to be resistent to it. :-)
I do recommend the precidence hierarchy. First check for property with the name, then check for the field. Otherwise, we'll need to have specific mappings like this:
<result property="FirstName" column="FNAME"/>
<result field="LastName" column="LNAME"/>
Cheers,
Clinton
On 7/12/06,
Gilles Bayon <[EMAIL PROTECTED]> wrote:
On 7/13/06, Clinton Begin < [EMAIL PROTECTED]> wrote:Hi guys,
Are you aware that field names conflict with property names when automapping columns? So a class written like:
public class Customer
{
private int id;
public int ID
{
get { return id; }
set { id = value; }
}
}
... will cause iBATIS.NET to fail with:
CustomerRepositoryTest.ShouldGetCustomerByID : IBatisNet.DataMapper.Exceptions.DataMapperException : Error automapping columns. Cause: Item has already been added. Key in dictionary: 'ID' Key being added: 'ID'
----> System.ArgumentException : Item has already been added. Key in dictionary: 'ID' Key being added: 'ID'
Seems like we're using the same map for fields and properties. I suppose the solution is to not. :-)The MS .NET guidelance is to prefix private field with an underscore, this will resolve the conflict name for now.
I think we should probably have two maps, one for fields, one for properties and then make a decision like: "properties always take precidence over fields if both exist" (favouring encapsulation).I don't see thing like this, a property in a parameter map/result map is only used to define a mapping of a property or a field not the two. The rule is : the .net member name must permit to distinguish one from to other.I think we can avoid make the decision like: "properties always take precedence over fields if both exist".I will try to resolve this.
Thoughts?
Clinton
