代码之家  ›  专栏  ›  技术社区  ›  Ben McNiel

对DevExpress XPO ORM包有什么想法吗?[关闭]

  •  23
  • Ben McNiel  · 技术社区  · 18 年前

    XPO 是我公司选择的对象关系映射器。对利弊有什么看法吗?


    我只是在寻找关于这个产品的一般感觉和趣闻轶事。我们不会换成XPO。我们正在摆脱应用程序中的硬编码sql字符串,并将所有数据访问完全转移到ORM。

    9 回复  |  直到 14 年前
        1
  •  16
  •   Jeremy McGee    18 年前

    其他人可能会使用技术解答(例如查询语法、使用缓存、易用性或其他方式映射到现有数据库结构)——但是如果有一个已建立的ORM层,答案很可能是

    “为什么要改变”?

    多年来,我成功地将XPO应用于一个已有几百个用户的商业产品中。我发现它很快,很灵活,做的工作。我认为目前没有必要改变,因为我们的数据量并不是特别大,缺点(主要是缓存)是我们可以解决的。

    如果我重新开始,我肯定会同时考虑NHibernate和ADO.NET实体框架。但实际上,一切都是好的;在技术问题之前,我很可能先看一下项目的商业情况。

    例如,NHibernate是开源的——是否有一个可行的社区来支持这个工具并提供(如有必要)商业支持?

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

    ADO.NET实体框架来自微软,微软以经常改变数据库技术而臭名昭著,而拉里则用飞机燃料来填充他的战斗机——这也会消失吗?

        2
  •  10
  •   Anders Rune Jensen    17 年前

    我发现与XPO合作非常令人沮丧。ORM的主要思想是抽象底层数据结构。但很快你就会注意到它们的默认字符串长度硬编码为60个字符,所以你最终会在每个字符串周围添加这些难看的字符串。太抽象了。。。

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

    因此,虽然对于简单类型来说它可以正常工作,但是当您想要存储更复杂的东西时,它很快就会崩溃。再加上他们平庸的支持,真的还有很多需要改进的地方。

        3
  •  4
  •   Steven Evers    17 年前

    我已经使用它6-7个月了,对我来说,卖主是他们所有的UI组件都与XPO相对无缝地工作,而且他们的UI组件是一流的。

    有些人可能会注意到,他们的论坛监控不力,几乎没有有用的流量——这是真的。但秘诀是填好票。他们对所有的支持票反应迅速,准确。

        4
  •  4
  •   Przemaas    14 年前

    XPO总体上很容易使用。然而,当您计划使用遗留数据库或尝试将其引入brownfield应用程序时,可能会有点痛苦。我遇到的最痛苦的障碍是:

    • 所有对象都需要从XPO相关类继承和/或使用XPO相关属性。所以,没有POCO对象
    • 不支持只读持久字段OOTB。这是可能的,但是您需要做一些黑客操作来阻止XPO更新DB中的字段
    • 不支持预筛选关联,这可能导致网络负载过大
    • 对外部组合键的支持不足。公平地说,没有ORM能够很好地处理组合键。它们被认为是“反ORM”模式。
    • 很少有小烦恼

    正如丹尼斯在评论中指出的,自从我最初写下这个答案以来,XPO有了很大的改进。特别是,以下事情不再是一个问题:

    • 没有序列化,因此XPO对象很难在断开连接的win-forms场景中使用,数据通过web服务传递。-XPO现在支持各种序列化方案,可以很容易地与WCF一起使用。
    • 不能使用自己的中间表进行多对多关系映射。Xpo需要此类临时表的特定名称。-这不再是个案子了
    • postgreSql provider中不支持枚举-您只需要编写非常简单的值转换器就可以了。

    另外,下面的问题将不再是下一个XPO版本的问题,将在今年晚些时候发布:

    • 不支持long类型的键
    • postrgeSql提供程序中不支持数据库架构

    总而言之,XPO有了很大的改进。大多数痛苦的障碍被消除了。使用遗留数据库时仍然可能遇到问题。但总体上XPO变得非常方便使用。

        5
  •  2
  •   Reverove Likia    15 年前

    XPO ver 10.2现在支持StoredProcedures和sqlquerys。参见信息 here ...

        6
  •  0
  •   Nicholas    18 年前

    利弊比较什么?有很多选择,最受欢迎的是nHibernate,在块上有一个新的孩子“ADO.NET实体框架”。

    不管怎样,根据你的情况和要求,有成百上千的答案。

        7
  •  0
  •   Dave Arkell    17 年前

    我喜欢这样一个事实,你可以只创建类,xpo为你创建表和关系-所以你可以从一个空白的数据库开始。

    我不喜欢的一个问题是,当我想删除一大堆东西时,它会遍历我的收藏,并对每一个进行删除。这需要很长时间,所以对于此类实例,我必须编写一些自定义sql(从blah所在的表中删除)。我不是XPO专家,但我就是这么发现的。

        8
  •  0
  •   Tomas Pajonk    17 年前

    我第二个事实是,删除带有一些集合的复杂对象需要非常非常长的时间。到目前为止,文档或论坛还不能帮我解决这个问题。

    除此之外,它的使用非常简单,让你走得很快。

    也很难计算出你的内存使用情况,我的设计中有复杂的大对象,使用它们比我想象的要占用更多的内存。

        9
  •  0
  •   Roman Eremin    16 年前

    这是开始编写域对象所需的全部操作(请尝试在其他系统中执行相同的操作):

    using System;
    using DevExpress.Xpo;
    using DevExpress.Data.Filtering;
    using NUnit.Framework;
    
    namespace XpoTdd {
        public class Person:XPObject {
            public Person(Session session) : base(session) { }
            public string FirstName { get; set; }
            public string LastName { get; set; }
            [Persistent]
            public string FullName { get { return FirstName + " " + LastName; } }
        }
        [TestFixture]
        public class PersonTests {
            [Test]
            public void TestPersistence() {
                const string connStr = "Integrated Security=SSPI;Pooling=false;Data Source=(local);Initial Catalog=XpoTddTest";
                UnitOfWork session1 = new UnitOfWork();
                session1.ConnectionString = connStr;
                Person me = new Person(session1);
                me.FirstName = "Roman";
                me.LastName = "Eremin";
                session1.CommitChanges();
                UnitOfWork session2 = new UnitOfWork();
                session2.ConnectionString = connStr;
                me = session2.FindObject<Person>(CriteriaOperator.Parse("FullName = 'Roman Eremin'"));
                Assert.AreEqual("Roman Eremin", me.FullName);
            }
        }
    }