Okay, the title is not saying too much, sorry. Essentially it’s an Architecture Question about an Application that can have multiple database backends (Well, “Database” is loosely used here as it can mean anything from MSSQL to XML Files to an IList in Memory), essentially involving the Repository Pattern.
I have a set of POCOs that essentially just serve as Data Transfer object (DTOs) and therefore do nothing except carry data. Unfortunately, I am seeing myself in the need to decorate them with Attributes i.e. for use with certain ORMs or even for use with the XmlSerializer. That means that they are now somewhat bound to the database layer and in my opinion not simple POCOs anymore.
From what I see, I would now have to duplicate these DTO-Classes, so that I have one Database-Specific class with Attributes and whatever I need, and a second version that is generic through my application. My Model would then have to convert them (which is where something like AutoMapper could be used)
It just still “feels weird” as I am essentially duplicating all my DTO Classes, yet the existence of Object-To-Object mappers seems to indicate that this is perfectly fine. Also, this seems to copy the ADO.net Approach whereas there is a Generic Part (down to the DataSet) and a Database-Specific part.
Is that correct? Or is there a different approach?
In the (somewhat limited) case of only needing to add Attributes for use with a given ORM, it is possible to write a wrapper that adds these things at runtime. You could add such code to the ORM constructor (subclassing the ORM or ORM initialization class as necessary), or to an ORM-initialization event.
An example is given below for tagging three properties with an attribute using Reflection, but it could be easily modified to add attributes to a type, or to all properties, etc.
Adapted from here. Just an idea – this is probably the first direction I’d head 🙂