关于DevExpress XPO ORM包的任何想法？

XPO是我公司选择的对象关系映射器.有关利弊的任何想法？

---

我只是在寻找关于该产品的一般感觉和轶事.我们没有转向XPO.我们正在摆脱存在于应用程序中的硬编码sql字符串,并完全移动到ORM以进行所有数据访问.

1> Jeremy McGee..：

---

其他人可能会提出技术答案(例如查询语法,使用缓存,轻松或以其他方式映射到现有数据库结构) - 但如果你有一个已建立的ORM层,那么答案可能就是

"为什么改变"​​？

我已经成功地使用XPO多年来已经建立了一个拥有数百名用户的商业产品.我发现它快速,灵活并且能够胜任.我认为目前没有必要改变,因为我们的数据量并不是特别大,而且主要是缓存(主要是缓存)是我们可以解决的问题.

如果我重新开始,我肯定会看看NHibernate和ADO.NET实体框架.但在实践中,一切都很好; 在技​​术问题出现之前,我很可能会考虑项目的商业情况.

例如,NHibernate是开源的 - 那里有一个可行的社区来支持该工具并提供(如有必要)商业支持吗？

XPO来自工具供应商,他们是否可能在产品的整个生命周期内保持业务？

ADO.NET实体框架来自微软,他因更频繁地更换数据库技术而臭名昭着,拉里用喷气燃料填充他的战斗机 - 这也会逐渐消失吗？

2> Anders Rune ..：

---

我发现XPO非常令人沮丧.ORM的主要思想是抽象出底层数据结构.但很快你就会注意到它们的默认字符串长度被硬编码为60个字符,因此你最终会在每个字符串周围添加这些丑陋的string.unlimited内容.抽象这么多......

在建模更复杂的对象时,您必须使用许多在对象模型中没有位置的语法,例如XPCollection.我想存储一个在类上有字符串字典的类,但遗憾的是XPO无法将其自动存储到数据库中.

因此,虽然它适用于简单类型,但是当您想要存储更复杂的东西时,它会很快崩溃.加上他们平庸的支持,真的让人感到很不满意.

---

我在上一份工作中使用它们多年,虽然不是用于xpo,但总是发现他们的支持非常出色.一直提起错误或功能请求,他们都很快得到回应.这些错误得到了很快的修复,他们没有任何问题,只能给我一个包含修复程序的每晚预发布链接.我所有关于如何使用它的问题也得到了同样快速的回答,通常还有示例代码.我努力提交质量问题,所以也许这就是原因.我认为在这些年里只有一个问题被标记为重复.很棒的公司,IMO.

---

默认情况下,字符串属性映射到大小为100的列.无论如何,您可以通过静态SizeAttribute.DefaultStringMappingFieldSize属性轻松更改默认大小(它只需要执行一次).此外,您可以通过使用SizeAtrribute标记它们来控制各个属性的大小,例如C#中的[Size(255)].更多详细信息可以在http://documentation.devexpress.com/#XPO/clsDevExpressXpoSizeAttributetopic找到.最后,您甚至可以通过DBTypeAttribute指定属性映射到的列的数据库类型,例如[DbType("smalldatetime") ]

---

XPO太糟糕了：我们在内存泄漏方面有很多问题，而且对象的顺序也不可靠。远离此ORM，使用更成熟的方法，而不要依赖明天或明年可能不在这里的第三方公司。