Question

好的，标题不是说太多，抱歉。本质上，它是一个关于可以拥有多个数据库后端的应用程序的架构问题（嗯，“数据库”在这里被广泛使用，因为它可能意味着从MSSQL到XML文件到内存中的IList），基本上涉及存储库模式。

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

从我看到的，我现在必须复制这些DTO类，以便我有一个特定于数据库的类，包含属性和我需要的任何内容，以及第二个通过我的应用程序通用的版本。然后我的模型必须转换它们（可以使用类似AutoMapper的地方）

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

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

Answer 1

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

下面给出了一个示例，用于使用Reflection标记具有属性的三个属性，但可以轻松修改它以将属性添加到类型或所有属性等。

 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;
            }
        }
}

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

Answer 2

当您在POCO中包含这些属性时，您应该问自己出了什么问题。特别是如果你的POCO只做携带数据并且不作为具有业务逻辑的域模型，那么你希望在属性中暴露出“技术细节”。在这种情况下，这些属性的唯一缺点似乎是将较低级别的技术细节稍微泄漏到较高级别。但这是否证明了一个全新的层，你只能做“愚蠢的属性复制”。我可能会说不。

简而言之：始终要仔细考虑感知问题的解决方案是否不会导致其他问题（甚至可能更大）。在你说明的情况下，我自己不会过分担心这些属性。如果有的话，我宁愿寻找选项来保持POCO的属性，并将它们放在其他资源（类或配置文件）中，而不是引入额外的转换层。

拥有多个后端/ DI - 架构时，ORM和POCO？ AutoMapper？

2 个答案: