Allow OR Mapping to be defined in a config file instead of attributes
Classes generated by SQL Metal have attributes placed on them that define their mapping to the underlying database.
Every time a changes occur in the mapping (e.g. A column name or size changes), the attributes on the class must be updated and thus must be recompiled.
This prevents using those classes as DTO (Data Transfer Object) in an nTier app ;where the assembly containing those classes would be shared between the client and the server; as it would require the client to be updated every time a column name changes on the server side.
Attribute-based mapping could easily be defined in a config file, adding tons of value to this project and separating matters in a more convenient way.
Francois,
Thanks for the feedback about mapping file. We have received feedback from both those who prefer attributes and those who would like to see a mapping file. S we are reevaluating the tradeoffs. I have discussed both sides of the coin on my recent blog post as well.
Thanks.
Dinesh Kulkarni
Program Manager - The LINQ Project
http://blogs.msdn.com/Dinesh.Kulkarni/
Well.... I don't have the code on hand...
But if you're not to provide both implementations, it would be at least a gread idea to define a structure for this mapping and allow a provider pattern that can be overriden by any other mapping source.
| |
interface IMappingSource
{
DatabaseMapping GetMapping();
}class DatabaseMapping
{
public TableMapping[] Tables
} class TableMapping
{
public Type Type;
public string TableName;
...
public ColumnMapping[] Columns;
} class ColumnMapping
{
Key = ...
...
}
|
By default you could provide the Attribute-based implementation while allowing it to be overriden by a config one.
In a way, you can read the OR mapping from a config file now. All you need to do is create your own attributes that inherit from ColumnAttribute and/or TableAttribute and then set the properties eg. Name using your own logic - say from a config file.
public class TestAttribute : ColumnAttribute
{
public TestAttribute(string propertyName)
{
Name = GetNameFromConfigFile(propertyName)
}
}My testing so far shows DataContext picks up the TestAttribute attribute and uses the custom logic to get the column name. No doubt there will be some limitations, but this may satisfy some of your needs.
