Data Table to Business Object Mapping.
In the past while I have looked into several techniques adopted for mapping relational data to business object. In O/R mappers, there seems to be two main methods, using XML files or Attributes.
I am just curious, why not just use static methods?
Code:
public interface IBaseBusinessObject
{
string GetTable();
Dictionary<string,string> GetMapping();
}
public class MyBusinessObject : IBaseBusinessObject
{
static string tableName = "MyTableName";
static Dictionary<string, string> mapping = new Dictionary<string,string>
{
{"PropertyA", "ColumnA"},
{"PropertyB", "ColumnB"},
{"PropertyC", "ColumnC"}
}
public static string GetTable()
{
return tableName;
}
public static Dictionary<string,string> GetMapping()
{
return mapping;
}
}
To me it seems to make more sence mapping using this method then having to deal with reading attributes. But, I have yet to see an O/R Mapper implemented in this way and I am wondering why not?
Any thoughts?
Mike B
Re: Data Table to Business Object Mapping.
Ok, so two problems with the above:
1) Cannot implement interface methods as static.
2) My dictionary creation as shown will not compile. I did see an example like this, but.....
Mike B
Re: Data Table to Business Object Mapping.
I'm not sure about .NET but with Hibernate on Java you use annotations for the mapping.
Looks something like this
class Foo
{
@Id
@Generated
private int Id;
}
This keeps the mapping with the code and I find it pretty useful when compared to the alternative xml mapping.
Re: Data Table to Business Object Mapping.
This is java's equivalent of attributes.
Re: Data Table to Business Object Mapping.
Quote:
Originally Posted by
MikeB
2) My dictionary creation as shown will not compile. I did see an example like this, but.....
The example is OK, it is syntaxt of initializer introduced in C#3.0
Re: Data Table to Business Object Mapping.
Why not use static methods? Because they are not flexible. You can use them for your proprietary solution, but they are not suitable for frameworks, where high flexibility is the must. (Personally, I try to avoid static methods at all). I think that XML files approach is the best because 1. language independant (fits C# as well as VB.NET), 2. it can be easily created and processed by third party tools.