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.

Answer this question

Allow OR Mapping to be defined in a config file instead of attributes

LYx
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.
Alfo

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/

I. Silvestri

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.

DIW
We hear you. We are looking into it. It is a cost-benefit tradeoff.
Allow OR Mapping to be defined in a config file instead of attributes

Answer this question