对 DevExpress XPO ORM 包有什么想法吗?

发布于 2024-07-04 15:22:19 字数 217 浏览 7 评论 0原文

XPO 是我公司选择的对象关系映射器。 对优点和缺点有什么想法吗?


我只是在寻找有关该产品的总体感觉和轶事。 我们不会切换到 XPO。 我们只是摆脱了应用程序中的硬编码 sql 字符串,并完全转向 ORM 来进行所有数据访问。

XPO is the object relational mapper of choice at my company. Any thoughts on the pros and cons?


I was just looking for general feeling and anecdotes about the product. We are not switching to XPO. We are just getting rid of hard coded sql strings living in the app and moving completely to ORM for all data access.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(9

飘逸的'云 2024-07-11 15:22:19

我发现使用 XPO 非常令人沮丧。 ORM 的主要思想是抽象出底层数据结构。 但很快您就会注意到它们将默认字符串长度硬编码为 60 个字符,因此您最终会在每个字符串周围添加这些丑陋的字符串。无限的东西。 抽象就这么多了……

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

因此,虽然它适用于简单类型,但当您想要存储更复杂的东西时,它很快就会崩溃。 再加上他们平庸的支持,确实还有很多不足之处。

I have found XPO very frustrating to work with. The main idea of an ORM is to abstract away the underlying data structure. But very quickly you'll notice that they have the default string length hardcoded to 60 chars, so you end up adding these ugly string.unlimited things around every string. So much for abstraction...

When modelling more complex object you have to use a lot of syntax that really has no place in your object model, like XPCollection. I wanted to store a class which had a dictionary of strings on the class, but sadly XPO was not able to automatically store this into the database.

So while it works ok for simple types, it very quickly breaks down when you want to store more complex things. That combined with their mediocre support really leaves a LOT to be desired.

遗弃M 2024-07-11 15:22:19

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

有些人可能会注意到他们的论坛监控不力并且几乎没有有用的流量 - 这是事实。 秘诀就是填写门票。 他们对所有支持请求做出快速、准确的响应。

I've been working with it for 6-7 months now and the seller for me was the fact that all of their UI components work relatively seamlessly with XPO - and their UI components are top notch.

Some might note that their forums are poorly monitored and have little useful traffic - this is true. The secret is to fill out tickets though. They respond quickly, and accurately to all of their support tickets.

鹿! 2024-07-11 15:22:19

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

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

正如 Dennis 在评论中指出的那样,自从我最初写这个答案以来,XPO 得到了很大的改进。 特别是,以下问题不再是问题:

  • 没有序列化,因此 XPO 对象很难在断开连接的 win 表单场景中使用,数据来自 Web 服务。 - XPO 现在支持各种序列化方案,并且可以轻松与 WCF 一起使用。
  • 您无法使用自己的临时表进行多对多关系映射。 Xpo 希望为此类临时表指定特定名称。 - 这不再是
  • postgreSql 提供程序中不支持枚举的情况 - 您只需要编写非常简单的值转换器,就可以了。

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

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

总而言之,XPO 得到了极大的改进。 大多数令人痛苦的障碍都被消除了。 在使用旧数据库时,您仍然可能会遇到问题。 但总的来说,XPO 使用起来相当方便。

XPO in overall is easy to work with. However, it can be a little pain when you plan to work with legacy database or try to introduce it into a brownfield app. Most painful obstacles I hit were:

  • all objects need to inherit from XPO related classes and/or use XPO related attributes. So, no POCO objects
  • no support for readonly persistent fields OOTB. It's possible, but you need to do a little hacking to stop XPO from updating field in DB
  • no support for pre filtering associations, which can cause excessive network load
  • Poor support for foreign composite keys. To be fair, no ORM handles composite keys nicely. They are considered to be "anti-ORM" pattern.
  • few small annoyances

As Dennis pointed out in comments, XPO was greatly improved since I wrote this answer originally. In particular, below things are no longer an issue:

  • no serialization, so XPO objects are hard to use in disconected win forms scenario, with data coming through web services. - XPO supports now various serialization scenarios and can be easily used with WCF.
  • you cannot do many-to-many relation mapping with your own interim table. Xpo wants specific name for such interim tables. - This is no longer a case
  • no support for enums in postgreSql provider - You just need to write really simple value converter and you are good.

Also, below issues will no longer be problem with next XPO release, coming later this year:

  • no support for keys of type long
  • no support for db schema in postrgeSql provider

All in all, XPO was greatly improved. Most painfull obstacles were removed. You can still hit problems while working with legacy DB. But in general XPO became quite convenient to use.

梅窗月明清似水 2024-07-11 15:22:19

相比之下有什么优缺点? 有很多替代方案,最流行的是 nHibernate,还有新的“ADO.NET 实体框架”。

无论如何,根据您的情况和要求,有数百个答案。

The pros and cons compared to what? There are a lot of alternatives out there, the most popular being nHibernate, with the new kid 'ADO.NET Entity Framework' on the block.

Anyways, there are hundreds of answers depending on your situation and requirements.

茶色山野 2024-07-11 15:22:19

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

我不喜欢的一个问题是,当我想删除一大堆东西时,它会遍历我的集合并对每一个进行删除。 这需要很长时间,所以对于这种情况,我不得不编写一些自定义sql(从表中删除)。 我不是 XPO 方面的专家,但这就是我发现的。

I like the fact that you can just create classes, and xpo creates the tables and relationships for you - so you can start from a blank database.

One issue I don't like is when I want to delete a whole bunch of stuff, it will go through my collection and do a delete on each one. This takes ages, so for this kind of instance, I've had to write some custom sql (delete from table where blah). I'm no expert on XPO, but that's what I found.

薄荷→糖丶微凉 2024-07-11 15:22:19

我同意删除某些集合中的复杂对象需要非常非常长的时间。 到目前为止,文档或论坛无法帮助我解决此问题。

除此之外,它使用起来非常简单,并且可以让您快速上手。

弄清楚你的内存使用情况也很困难,我的设计中有复杂的大对象,并且使用它们比我想象的要消耗更多的内存。

I second the fact the deleting complex objects with some collections take really, really long. So far the documentation or the forums were not able to help me with this.

Apart from that it is really simple to use and gets you going quickly.

It is also quite hard to figure out your memory usage, I had complex big objects in my design and working with them was a memory hog bigger than I had assumed.

双马尾 2024-07-11 15:22:19

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

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

This is all you need to do to start writing your domain objects (try do the same in other systems):

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);
        }
    }
}
够运 2024-07-11 15:22:19

XPO 版本 10.2 现在支持 StoredProcedures 和 SqlQueries。 查看信息
此处...

XPO ver 10.2 now supports for both StoredProcedures and SqlQueries. See infomation
here...

我ぃ本無心為│何有愛 2024-07-11 15:22:19

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

“为什么要改变”?

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

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

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

XPO 来自工具供应商,他们是否有可能在产品的整个生命周期内继续经营?

ADO.NET 实体框架来自 Microsoft,该公司因更改数据库技术的频率比拉里给他的战斗机加注喷气燃料还要频繁而臭名昭著 - 这也会消失吗?

Others will probably pitch in with technical answers (e.g. the query syntax, use of caching, ease or otherwise of mapping to an existing database structure) -- but if you have an established ORM layer the answer is probably

"Why change"?

I've used XPO successfully for years in an established commercial product with several hundred users. I find that it's fast, flexible and does the job. I don't see any need to change at the moment, as our data volumes aren't particularly large and the foibles (caching, mostly) are things we can work around.

If I were starting afresh I'd definitely look at both NHibernate and the ADO.NET Entity Framework. In practice, though, all are good; I'd most likely look at the commercial situation for the project ahead of the technical questions.

For instance, NHibernate is open-source -- is there a viable community there to support the tool and to provide (if necessary) commercial support?

XPO comes from a tools vendor, are they likely to remain in business for the lifetime of the product?

ADO.NET Entity Framework comes from Microsoft, who are notorious for changing database technologies more often then Larry fills his fighter with jet fuel -- will this, too, fade away?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文