.net 当有多个后端/DI体系结构时的ORMs和POCO？汽车制造商？

好吧，标题没说太多，对不起。从本质上讲，这是一个关于一个可以有多个数据库后端的应用程序的架构问题（在这里，“数据库”是松散使用的，因为它可以表示从MSSQL到XML文件再到内存中的IList的任何内容），本质上涉及到存储库模式

我有一组POCO，它们基本上只是用作数据传输对象（DTO），因此除了携带数据之外什么都不做。不幸的是，我发现自己需要用属性来修饰它们，即用于某些ORMs，甚至用于XmlSerializer。这意味着它们现在在某种程度上绑定到数据库层，在我看来不再是简单的POCO了

据我所见，我现在必须复制这些DTO类，这样我就有了一个特定于数据库的类，带有属性和我需要的任何东西，还有一个通过我的应用程序通用的第二个版本。然后，我的模型必须转换它们（这是可以使用类似的东西的地方）

它仍然“感觉很奇怪”，因为我实际上是在复制我所有的DTO类，然而对象到对象映射器的存在似乎表明这是完全正确的。此外，这似乎是复制ADO.net方法，而有一个通用部分（一直到数据集）和一个特定于数据库的部分

对吗？或者有不同的方法吗？

在只需要添加用于给定ORM的属性的情况下（有些有限），可以编写一个在运行时添加这些内容的包装器。您可以将此类代码添加到ORM构造函数（根据需要对ORM或ORM初始化类进行子类化）或ORM初始化事件中

下面给出了一个使用反射将三个属性标记为一个属性的示例，但是可以很容易地对其进行修改，以便将属性添加到类型或所有属性等

 PropertyDescriptor[] properties = TypeDescriptor.GetProperties(this);
 //Add as necessary
 string[] propertiesToTagForORM = { "Name", "Category", "Description" };

 foreach (string propname in propertiesToTagForORM)
        {
            PropertyDescriptor prop = properties[propname];
            if (prop != null)
            {
                AttributeCollection runtimeAttributes = prop.Attributes;
                // make a copy of the original attributes 
                // but make room for one extra attribute
                Attribute[] attrs = new Attribute[runtimeAttributes.Count + 1];
                runtimeAttributes.CopyTo(attrs, 0);
                attrs[runtimeAttributes.Count] = new BrowsableAttribute(false); 

                prop = TypeDescriptor.CreateProperty(this.GetType(), propname, prop.PropertyType, attrs);
                properties[propname] = prop;
            }
        }
}

---

改编自。只是一个想法-这可能是我的第一个方向：）

你应该问问自己，当你把这些属性包括在你的POCO中时，哪里出了问题。特别是如果您的POCO只传输数据，不作为具有业务逻辑的域模型，而您希望在属性中保留单独形式的“技术细节”。在这种情况下，这些属性的唯一缺点似乎是将较低级别的技术细节泄漏到较高级别。但这是否证明了一个全新的层是合理的，在这个层中，您只需执行“愚蠢的属性复制”。我可能会说不

---

简言之：始终仔细思考一个感知问题的解决方案是否不会导致另一个问题（甚至更大的问题）。在你举例说明的情况下，我自己不会太担心这些属性。如果有什么区别的话，我宁愿寻找一些选项，将属性排除在POCO之外，并将它们放在其他资源（类或配置文件）中，而不是引入额外的转换层。

这是一个有趣的想法。基本上，我可以将我的后端作为单独的程序集，并让它们根据需要操纵POCO。。。我肯定记得那种方法。的确。如果你尝试一下，你会得到关于它对你的效果的反馈。如果是这样，我想，如果我有3或4个不同的“元数据集”，它们可能是混乱的，这是我关心的。我理解，但是要仔细考虑混乱的实际程度，如果添加额外的转换和类不会使事情变得更复杂和更复杂。我见过太多的项目盲目地求助于DTO，事后看来，DTO并没有增加任何价值，但却产生了巨大的维护开销。在这种情况下，我真的很想打电话给雅格尼，直到证明不是这样。